[Saxdotnet-devel] StartElement, when URI is not present

[Jeff R. <li...@je...>]

We have been discussing the various possibilities of enforcing a rule 
about what to do when a URI is not present. For example consider this:

<foo></foo>

What should the StartElement call consist of?

QName : "foo"
LocalName : "foo"
Uri : null or string.Empty?

The Java SAX API claims that string.Empty should be used:

   "The Namespace URI, or the empty string if the element has no
   Namespace URI or if Namespace processing is not being performed."
   (pointed out by Elliotte Harold)

but this is problemetized by additional wording which is not so clear:

   Code using element names would normally match first for a null URI,
   and if it's null then use qName otherwise use localName

   http://www.saxproject.org/?selected=namespaces

and further down:

   If the URI were the emtpy string, you would normally use the qName
   to identify attributes. So code looking at those attributes would
   normally match first for a null URI, and if it's null then use
   qName otherwise use the localName.

   (both pointed out by Karl)

In any event the SAX for .NET API needs to take a clear position and run 
with it. Currently it appears that Karl is leading the charge for going 
with null as the default value and I am pushing string.Empty. Here are 
some of our arguments:

Karl:
=====

I am not saying that I am against String.Empty, but from
a programming point of view it is simply a weaker choice.

- null indicates absence better than picking a special value.
- what if an empty string ever got a special meaning for URIs?

If we pick the emtpy string, then we do it for reasons
other than API quality. So, the way I see it, we have to
clarify how important Java compatibility is.

Jeff:
=====
All of the proposed changes pretty high level and fully backwards 
compatabile (with the exception of entityResolver)... the 
null/string.empty will require making changes to actual handler 
internals-- the guts of filters that people have written-- and it will 
be very very easy to miss when converting. If you don't port the 
entityReolver code you have from Java correctly you will get a compile 
time error, if you forget that Java mandated string.empty and the .NET 
version mandates null you will get a runtime error.


So to summarize: Karl is arguing for using null because it is a better 
API choice. Jeff is arguing for string.Empty because it is more 
compatabile with the Java version (though as Karl has argued, there is a 
high degree of incompatibility as it is already).

Thanks,
Jeff Rafter