[jdom-interest] XMLOutputter & null pointer exception.

[Bolt, Dave]

Tako,

I basically agree with you, the problem is not a JDOM problem. It is a
problem with the
XML standard. Unfortunately the XML standard is what it is. 

Since the XML spec is silent on the proper way to encode an empty string
verses a null I
understand that tools like JDOM can't offer much help and that developers
will be forced
to use workarounds such as you have provided.

I guess my main reason for bothering the mailing list with this issue is to
point out this
problem for the masses. Many developers are working right now to develop B2B
bridges between
relational databases. Most of them will probably never read the XML spec. If
they miss the
semantic indifference of XML regarding empty strings and NULLs they will get
burnt.

Dave Bolt
ATSC/SPAWAR ASAT Team
Bolt's Law of Bandwidth - There is always plenty of network bandwidth, just
none for you.


-----Original Message-----
From: Tako Schotanus [mailto:tako at backstream.com]
Sent: Wednesday, August 16, 2000 10:17 AM
To: Bolt, Dave
Subject: RE: [jdom-interest] XMLOutputter & null pointer exception.



The problem I think here is that you are now comparing apples and oranges.
In a database there is a difference between an empty string and the absence
of data (NULL). As far as I know the XML standard says that there is no
semantical difference between <foo></foo> and <foo/>. So there is actually
no way to distinguish the two, so why should you be able to in JDOM? I think
it would even be plain wrong to do so. Your case could easily be handled
this way:

<record>
  <field name="id">1234</field>
  <field name="title">The unbearable lightness of being</field>
  <field name="author" isnull="true" />
</record>

The only thing JDOM should do when you read a document and later write it is
make sure that the resulting document is 100% semantically the same. That
you added further meaning to the way the document was at first layed out is
of no importance to the XML standard I think.

-Tako


> The real question is that of fidelity. If you view XML (and JDOM by
> extension) as a "pipe",
> the data I put in should be the data that I get out.
> 
> Consider the situation of someone building an XML bridge between two
> databases. Imagine a
> table in each database called Employee. Let's assume that the 
> field holding
> the middle
> name is an empty string, but not NULL. If I serialize the data from DB #1
> into XML via
> JDOM and then extract the data for use in DB #2 JDOM will have turned my
> empty string into
> a Java null. So use of XML and JDOM has changed my data.
> 
> The best approach would maintain the fidelity of the data, but it is going
> to be difficult
> to decide the appropriate way to handle the data. Clearly an empty tag
> should return NULL
> when someone tries to get the tag's content. The problem is how 
> do we handle
> an empty string
> so that it does not get translated into a NULL.
> 
> Dave Bolt
> ATSC/SPAWAR ASAT Team
> Bolt's Law of Bandwidth - There is always plenty of network 
> bandwidth, just
> none for you.
> 
> 
> -----Original Message-----
> From: Jason Hunter [mailto:jhunter at collab.net]
> Sent: Tuesday, August 15, 2000 8:20 PM
> To: Quigley, James P
> Cc: jdom-interest at jdom.org
> Subject: Re: [jdom-interest] XMLOutputter & null pointer exception.
> 
> 
> "Quigley, James P" wrote:
> > 
> > The larger issue is whether getText should return null for an empty 
> > String.
> > I looked at getTextTrim and it will
> > return an empty String. I'd expect the two methods to return identical
> > values for an empty string. My preference
> > would be the empty string to avoid pesky null pointer exceptions.
> 
> In one way it's actually a bug in Element, because a setText("") creates
> an empty String content node but then a getText() right after returns
> null.  That caused XMLOutputter to get confused when it saw a single
> String content node but got the null from getText().
> 
> I just did a CVS check-in so 'setText(""); getText()' returns "".  That
> at least makes things work in the interim.
> 
> Now let's decide what we want long term.  What should getText() and
> getMixedContent() return for all these?
> 
> <empty/>
> <empty></empty>
> setText("")
> setText(null)
> 
> Having all return null for getText() and empty lists for
> getMixedContent() seems like the best choice after 15 seconds of
> thinking.  That would mean setText("") would act like setText(null).
> 
> -jh-
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/yourad
dr at yourhos
t.com
_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com