xml-dev - Display value e.g. "Unknown" for a Null valued element

["Tolkin, Steve" <Steve.Tolkin@fmr.com>]

Summary:
We are sending data from a relational database to xml, and from there
to our client tools and/or another database.  
Some of the database fields have null values.  
When there is a null value we want the client tool to display an
explicit value to represent this (rather than it being implied by the
absence of an optional element).  
This is not a straightforward decision because XML allows many
different ways to do something, and because it is still evolving.
This note discusses some of the possible techniques.
We are interested in getting feedback, e.g. other alternatives, 
different tradeoffs, issues we have missed, etc.

Details:
Requirements:
Have a way to transmit Null values from the database.
Have an explicit display value for the Null value, e.g. "Unknown".
Have the xml, not the client, determine the display value for null.
Have a data type for each element, e.g. int (or Null).

Secondary Goals:
Keep the code in the clients simple.
Prefer approved W3C Recommendations, e.g. prefer DTD to XML-Schema.
Prefer consistency with likely W3C futures, e.g. XML-Schema.
Prefer that our clients use SAX rather than DOM.
Allow good time and space performance of the clients.
Allow loading the xml into a relational database.
Allow schema migration (e.g. add elements) with minimal client impact.
Allow the xml to be displayed even without a DTD.
Allow the xml to be displayed in a simple viewer, e.g. Microsoft IE.
Allow different elements to have different display values for null.

Some Possible Implementations (in order of perceived "goodness"):

0. Set the element content to the display value for Null, e.g. "Unknown".
Con: Violates data typing.

1. In the DTD make the element optional, e.g. someElement?
Then omit it to indicate the Null value.
Con: The client must detect the absence of this field.  In general
this is hard.  There is no built in support for this using SAX.
Con: When the xml is displayed in a simple viewer, there is no
indication of this element. 

2. Associate with each nullable element another element to hold the
display value for Null, e.g. someElementNull.
In the DTD specify that exactly one must occur, e.g.
(someElement|someElementNull).  Then send one of these in the xml,
e.g. <someElementNull> Unknown </someElementNull>.
Pro: This supports all the requirements.
Con: The client code has a Java class for each element type.  In the
worst case this approach will double the number of classes.  This
makes the code more complex to write, and somewhat larger and slower.
Con: In the simple viewer it looks ugly.
Con: This makes it harder to load the xml into a relational database.

3. Associate with each nullable element an optional
attribute to hold the value to be used to display a Null value.
For example add an attribute named nullDisplay and then
in the xml file have nullDisplay="Unknown".  
(If we later adopt XML-Schema we could add a second attribute,
i.e. in the Schema say the element is nullable,
and in the xml document add xsi:null="true".) 
Pro: This supports all the requirements.
Pro: This seems consistent with the direction of XML-Schema.
Con: The client tool needs logic to handle the nullDisplay attribute.
Con: XML-Schema will not be able to check the constraint that the
nullDisplay attribute should appear if and only if xsi:null is "true".
To check this ourselves we need to write some code, or a query.

There are many more variations possible, e.g. the use of entities to
hold the display value for null.  (Each nullable element would have
one associated entity, but many element could have the same one.)
This would ensure consistency when creating the xml document, and
simplify changing the display value, e.g. to "N/A".

-- 
Steven Tolkin          steve.tolkin@fmr.com      617-563-0516 
Fidelity Investments   82 Devonshire St. R24D    Boston MA 02109
There is nothing so practical as a good theory.  Comments are by me, 
not Fidelity Investments, its subsidiaries or affiliates.

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************