saxdotnet-devel

[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

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

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

I wanted to add that the outcome of this discussion will also affect the 
StartPrefixMapping calls. In the event of:

   <foo xmlns="http://www.example.org">

The "prefix" in the callback can either be null or string.empty.

Jeff

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

[Elliotte H. <el...@me...>]

Jeff Rafter wrote:

> 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?


This really, really, really needs to be the empty string, unless null 
works very differently in C# than in Java. It's just incredibly useful 
to be able to assume the namespace URI (and other arguments to this 
method) are never null. I see this again and again in my SAX work. API 
quality wise, null should be avoided here.

> 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?

It already has a special meaning for URIs and namespace URIs. There's 
approximately zero chance of this changing.

XML-wise these two elements are equivalent:

<data />
<data xmlns="" />

Unless you're prepared to use null for both of them, which I think would 
be harder for implementers, you need to pick the empty string here. 
Unlike SQL, XML namespaces do not distinguish between the empty string 
and no value. Namespaces in XML says, "The default namespace can be set 
to the empty string. This has the same effect, within the scope of the 
declaration, of there being no default namespace."

-- 
Elliotte Rusty Harold  el...@me...
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim

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

[Karl W. <ka...@wa...>]

> Jeff Rafter wrote:
> 
> > 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?
> 
> 
> This really, really, really needs to be the empty string, unless null 
> works very differently in C# than in Java. It's just incredibly useful 
> to be able to assume the namespace URI (and other arguments to this 
> method) are never null. I see this again and again in my SAX work. API 
> quality wise, null should be avoided here.

I can understand this, but you would usually check the Uri anyway,
since you want to know if the name has a namespace. So you would
get used to "if (uri == null)" fairly quickly.

In general, using a special value to indicate presence or absence
of the value is more fragile than using a separate indicator.
Most general, this should be a separate boolean flag, as some
types (integers, booleans) do not provide the extra level
of indirection that allows the use of null. In this case however,
we have a reference type (C# lingo).

> 
> > 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?
> 
> It already has a special meaning for URIs and namespace URIs. There's 
> approximately zero chance of this changing.

Somewhat confusing is that RFC 2396 assigns some semantics to empty URIs:
<quote>
4.2. Same-document References

   A URI reference that does not contain a URI is a reference to the
   current document.  In other words, an empty URI reference within a
   document is interpreted as a reference to the start of that document,
   and a reference containing only a fragment identifier is a reference
   to the identified fragment of that document.  Traversal of such a
   reference should not result in an additional retrieval action.
   However, if the URI reference occurs in a context that is always
   intended to result in a new request, as in the case of HTML's FORM
   element, then an empty URI reference represents the base URI of the
   current document and should be replaced by that URI when transformed
   into a request.
</quote>

> 
> XML-wise these two elements are equivalent:
> 
> <data />
> <data xmlns="" />
> 
> Unless you're prepared to use null for both of them, which I think would 
> be harder for implementers, you need to pick the empty string here. 

xmlns="" is just syntax for null, as it means that there is no default
namespace (where one might have been before), it doesn't mean that the
default namespace has an empty string as URI (which is not a valid URI).

> Unlike SQL, XML namespaces do not distinguish between the empty string 
> and no value. Namespaces in XML says, "The default namespace can be set 
> to the empty string. This has the same effect, within the scope of the 
> declaration, of there being no default namespace."
>

See above.

Karl

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

[Elliotte H. <el...@me...>]

Karl Waclawek wrote:


> I can understand this, but you would usually check the Uri anyway,
> since you want to know if the name has a namespace. So you would
> get used to "if (uri == null)" fairly quickly.

In fact, I find that I don't do that nearly as often as you'd think. As 
long as I know the URI is not null there are a lot of cases where I can 
treat the empty space exactly the same as any other namespace. If I had 
to worry about it being null, I absolutely couldn't do that and I'd have 
to litter my code with a lot of null checks or catch 
(NullPointerException). It just works out cleaner to be able to treat no 
namespace the same as any other namespace. which I can do most (not all) 
of the time if it's the empty string and none of the time if it's null.


> Somewhat confusing is that RFC 2396 assigns some semantics to empty URIs:
> <quote>
> 4.2. Same-document References
> 
>    A URI reference that does not contain a URI is a reference to the
>    current document.  In other words, an empty URI reference within a
>    document is interpreted as a reference to the start of that document,
>    and a reference containing only a fragment identifier is a reference
>    to the identified fragment of that document.  Traversal of such a
>    reference should not result in an additional retrieval action.
>    However, if the URI reference occurs in a context that is always
>    intended to result in a new request, as in the case of HTML's FORM
>    element, then an empty URI reference represents the base URI of the
>    current document and should be replaced by that URI when transformed
>    into a request.
> </quote>

This is irrelevant here. namespace URIs do not indicate any document, 
whether they're the empty string or not.


> xmlns="" is just syntax for null, as it means that there is no default
> namespace (where one might have been before), it doesn't mean that the
> default namespace has an empty string as URI (which is not a valid URI).

There is no such thing as null in XML. The concept of null is completely 
foreign to it. There is no null namespace URI, no null element, no null 
value. I've seen developers of various stripes try to introduce null 
into XML, and it's almost always a disaster. There is null in Java and, 
I assume, C#. But this is not something that has any reflection in XML.

-- 
Elliotte Rusty Harold  el...@me...
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim

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

[Karl W. <ka...@wa...>]

> Karl Waclawek wrote:
> 
> 
> > I can understand this, but you would usually check the Uri anyway,
> > since you want to know if the name has a namespace. So you would
> > get used to "if (uri == null)" fairly quickly.
> 
> In fact, I find that I don't do that nearly as often as you'd think. As 
> long as I know the URI is not null there are a lot of cases where I can 
> treat the empty space exactly the same as any other namespace. If I had 
> to worry about it being null, I absolutely couldn't do that and I'd have 
> to litter my code with a lot of null checks or catch 
> (NullPointerException). It just works out cleaner to be able to treat no 
> namespace the same as any other namespace. which I can do most (not all) 
> of the time if it's the empty string and none of the time if it's null.

As I said before, I am not dead-set against String.Empty.
If the majority of discussion participants vote for it, then
I will change it in the API. 
 
> > Somewhat confusing is that RFC 2396 assigns some semantics to empty URIs:
> > <quote>
> > 4.2. Same-document References
> > 
> >    A URI reference that does not contain a URI is a reference to the
> >    current document.  In other words, an empty URI reference within a
> >    document is interpreted as a reference to the start of that document,
> >    and a reference containing only a fragment identifier is a reference
> >    to the identified fragment of that document.  Traversal of such a
> >    reference should not result in an additional retrieval action.
> >    However, if the URI reference occurs in a context that is always
> >    intended to result in a new request, as in the case of HTML's FORM
> >    element, then an empty URI reference represents the base URI of the
> >    current document and should be replaced by that URI when transformed
> >    into a request.
> > </quote>
> 
> This is irrelevant here. namespace URIs do not indicate any document, 
> whether they're the empty string or not.

Well, this is not clear to me.
There is a current document, which has an URI, and the URI reference would point to it.
So, one could make a case that we have an URI and therefore a namespace.

> > xmlns="" is just syntax for null, as it means that there is no default
> > namespace (where one might have been before), it doesn't mean that the
> > default namespace has an empty string as URI (which is not a valid URI).
> 
> There is no such thing as null in XML. The concept of null is completely 
> foreign to it. There is no null namespace URI, no null element, no null 
> value. 

The concept of null is simply the concept of absence.
Since there is no special syntax provided, the above is the one
that has been assigned that meaning (for namespaces, not in general).

Karl

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

[Karl W. <ka...@wa...>]

Elliotte Harold wrote:
> Karl Waclawek wrote:
> 
> 
>> I can understand this, but you would usually check the Uri anyway,
>> since you want to know if the name has a namespace. So you would
>> get used to "if (uri == null)" fairly quickly.
> 
> 
> In fact, I find that I don't do that nearly as often as you'd think. As 
> long as I know the URI is not null there are a lot of cases where I can 
> treat the empty space exactly the same as any other namespace. If I had 
> to worry about it being null, I absolutely couldn't do that and I'd have 
> to litter my code with a lot of null checks or catch 
> (NullPointerException). It just works out cleaner to be able to treat no 
> namespace the same as any other namespace. which I can do most (not all) 
> of the time if it's the empty string and none of the time if it's null.

I had another look at the Java API.
It seems it is quite inconsistent with respect to empty string vs. null.

Examples:

- In EntityResolver, all occurrences of publicId or baseUri
   are supposed to be null, when absent.

- DTDHandler.notationDecl(): publicId, systemId can be null,
   if not provided

- DTDHandler.unparsedEntityDecl: publicId can be null if not provided

- DeclHandler.attributeDecl(): mode and value can be null, where
   in the latter there is actually a semantic difference between
   value = null (meaning: none defined) and value = empty string
   (meaning: a value is specified, and it is the empty string).

- DeclHandler.externalEntityDecl: publicId can be null, if not provided

- LexicalHandler.startDTD(): publicId, systemId can be null,
   if not declared

It actually seems that the prevalent approach is to use null for absence 
of a string parameter, and only in the case of namespaces does the API
stray from this rule.

However, I would strongly suggest that we remain consistent in
SAX for .NET. If we pick String.Empty, then we need to allow one
inconsistency - and that is for the Value parameter passed to the
attributeDecl() call-back.


Karl

Re: [Saxdotnet-devel] String.Empty vs. null (was: StartElement, when URI is not present)

[Karl W. <ka...@wa...>]

Trying to get the empty string vs. null discussion restarted.

Karl Waclawek wrote:

> 
> I had another look at the Java API.
> It seems it is quite inconsistent with respect to empty string vs. null.
> 
> Examples:
> 
> - In EntityResolver, all occurrences of publicId or baseUri
>   are supposed to be null, when absent.
> 
> - DTDHandler.notationDecl(): publicId, systemId can be null,
>   if not provided
> 
> - DTDHandler.unparsedEntityDecl: publicId can be null if not provided
> 
> - DeclHandler.attributeDecl(): mode and value can be null, where
>   in the latter there is actually a semantic difference between
>   value = null (meaning: none defined) and value = empty string
>   (meaning: a value is specified, and it is the empty string).
> 
> - DeclHandler.externalEntityDecl: publicId can be null, if not provided
> 
> - LexicalHandler.startDTD(): publicId, systemId can be null,
>   if not declared
> 
> It actually seems that the prevalent approach is to use null for absence 
> of a string parameter, and only in the case of namespaces does the API
> stray from this rule.
> 
> However, I would strongly suggest that we remain consistent in
> SAX for .NET. If we pick String.Empty, then we need to allow one
> inconsistency - and that is for the Value parameter passed to the
> attributeDecl() call-back.

Originally, this thread was about namespace URI references
and prefixes. The question was whether they should be passed
as empty strings or as null references when absent/not applicable.

However, whatever the outcome of this discussion, it should be applicable
to the whole API, but not as a general rule of either always null
or always empty. The reason is that in the case of DeclHandler.AttributeDecl(),
the "value" parameter has well defined meanings for both, empty string
and null, so both must be allowed depending on the intended semantics.

Maybe we should first ask, when such a problem of deciding
between an empty string or null actually exists?
I would say that is the case when the meaning of both
is "roughly" the same: an undefined or absent string value.

Two examples where I would intuitively make different decisions:

1) ParseError.Message, or SAXParseException.Message:
    In this case I would always assume that there is a message,
    even if it is an empty string. It looks wrong to me to
    even allow a null value.

2) Locator.PublicId: If there is no public identifier, then
    one should make its absence clear. null is better at that.

One could think of this as a guideline:

- If we would say: this string parameter/argument/value
   can be absent, then let's use null to indicate it.
- If we would rather say: this string parameter/argument/value
   can be empty, then let's use "" to indicate it.

Coming back to the SAX API:
How would the above guideline be resolved for namespace URIs
and prefixes when an XML name is not in any namespace?

Karl

Re: [Saxdotnet-devel] String.Empty vs. null

[Karl W. <ka...@wa...>]

Jeff Rafter wrote:
>> One could think of this as a guideline:
>>
>> - If we would say: this string parameter/argument/value
>>   can be absent, then let's use null to indicate it.
>> - If we would rather say: this string parameter/argument/value
>>   can be empty, then let's use "" to indicate it.
>>
>> Coming back to the SAX API:
>> How would the above guideline be resolved for namespace URIs
>> and prefixes when an XML name is not in any namespace?
> 
> 
> I think that these are good guidelines-- and tough to argue with... but 
> for namespace URIs I think there is some ambiguity still...
> 
> a) <foo/>
> b) <foo xmlns="http://foo"/>
> c) <foo xmlns=""/>
> 
> Most naturally I would see this as
> 
> a) null
> b) "http://foo"
> c) string.empty

Are you asking what to pass for the namespace uri of foo
in the StartElementHandler()?

a) don't know, depends if there is a default namespace
b) "http://foo"
c) null (there is no namespace for foo)

We really only have two cases: foo has a namespace, or it doesn't.

Or did you mean something else?

> But I could see this making for needlessly complex handler code. Which 
> is why we want to land on either null or string.empty. string.empty 
> gives you less chance of a runtime exception but does not represent case 
> (a) very well. Using null does not represent (c) very well. I think that 
> in the XML Corpus this is one of the few areas where "" has a specific 
> meaning. You brought up arguments about API consistency and should we 
> use string.empty if no Public ID is provided (for instance)... but what 
> about the case where you have:
> 
> <foo bar="">
> 
> Would the bar attribute's value be null or string.empty?

String.Empty. null would mean: no value.

Karl

Re: [Saxdotnet-devel] String.Empty vs. null

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

> We really only have two cases: foo has a namespace, or it doesn't.
> 
> Or did you mean something else?

<snip/>

>> <foo bar="">
>> Would the bar attribute's value be null or string.empty?
> String.Empty. null would mean: no value.
> 

This is the contradiction I am referring to... technically the value of 
bar is emtpy which is more or less null. But we make the distinction 
because it is helpful to know that even though there is no value, the 
attribute bar is present. This is the same as the xmlns="" declarations. 
Technically the value means null-- literally it is empty-- and it is 
helpful to be able to distinguish between the two (at least in editor 
applications)...

Jeff

Re: [Saxdotnet-devel] String.Empty vs. null

[Karl W. <ka...@wa...>]

Jeff Rafter wrote:
>> We really only have two cases: foo has a namespace, or it doesn't.
>>
>> Or did you mean something else?
> 
> 
> <snip/>
> 
>>> <foo bar="">
>>> Would the bar attribute's value be null or string.empty?
>>
>> String.Empty. null would mean: no value.
>>
> 
> This is the contradiction I am referring to... technically the value of 
> bar is emtpy which is more or less null. But we make the distinction 
> because it is helpful to know that even though there is no value, the 
> attribute bar is present. 

I am not sure if so documented, but if an attribute is passed
through SAX (IAttributes), it can never have a null value argument,
simply because an attribute without value is nonsense.
null means "no value" (see below).

 > This is the same as the xmlns="" declarations.
> Technically the value means null-- literally it is empty-- and it is 
> helpful to be able to distinguish between the two (at least in editor 
> applications)...

I don't quite agree - null means "no value". there is no null value
for strings. null is a value for references/pointers. The string
arguments in SAX are not strings, but string references, and as such
they can be null, meaning they do not point to any string object.

This is also one of the reasons why namespace URI references are not
allowed to be empty strings in XML, even though URI references in general
are allowed to, and do have a specific meaning assigned to an empty string.
Otherwise one could not express "absence" or "removal" of namespaces
in the serialized format, because XML is a text format - everything must
be expressed as text. xmlns="" can be interpreted on two levels:
1) an attribute with name xmlns and value "".
2) an expression of the fact that the default namespace is turned off.
The concept of null comes into play at a later stage, and that is
when the parser wants to pass a name to the app. How does it express
that this name has/does not have a namespace? If the uri argument,
which is a string reference, points to nothing (==null) then we don't
have an uri string object, and therefore no namespace.

So, I simply don't see a contradiction.

Karl

Re: [Saxdotnet-devel] String.Empty vs. null

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

> So, I simply don't see a contradiction.

It seems that we are the only ones arguing about this. Elliotte seemed 
to be in favor of string.empty as well and his last email on the subject 
was very strong-- but he also added the caveat that he is a Java guy for 
the sake of this discussion. So if we took a vote:

======================================
2 use string.empty for the URI param
when xmlns="" or xmlns is not present.

1 use null for the above
======================================

This would indicate that we would either need to change such params in 
other callbacks or live with the inconsistency.

Now of course, you are project admin and SAX is historically a 
dictatorship-- as the only other implementer I can tell you that I will 
implement it however you decide.

In any event-- we need to decide, we need to document the decision very 
clearly and we need to make sure our SAX conformance application checks 
for all of the appropriate cases. Which may involve adding a secondary 
test suite.

Cheers,
Jeff

Re: [Saxdotnet-devel] String.Empty vs. null

[Karl W. <ka...@wa...>]

Jeff Rafter wrote:
>> So, I simply don't see a contradiction.
> 
> 
> It seems that we are the only ones arguing about this. Elliotte seemed 
> to be in favor of string.empty as well and his last email on the subject 
> was very strong-- but he also added the caveat that he is a Java guy for 
> the sake of this discussion. 

When I asked David Meggisonso he said the orginal reason was
for programming convenience.

> So if we took a vote:
> 
> ======================================
> 2 use string.empty for the URI param
> when xmlns="" or xmlns is not present.
> 
> 1 use null for the above
> ======================================
> 
> This would indicate that we would either need to change such params in 
> other callbacks or live with the inconsistency.

I guess we already have one inconsistency at our hands that
we cannot bypass: In the AttributeDecl() call-back, there are
defined meanings for value=="" and value==null, so we must allow both.

One of the things Elliotte mentioned was passing the URI to
other libraries, instead of checking it. That is what D.Megginson probably
meant with convenience. So, which libs in .NET would one use?
And what do they accept? It would be funny if after all the
discussion they accepted null for an URI.

> Now of course, you are project admin and SAX is historically a 
> dictatorship-- as the only other implementer I can tell you that I will 
> implement it however you decide.

I am hesitant to dictate my opinion here. In the end, anything is workable.
Unfortunately not too much feedback.

If we go with String.Empty for URIs and prefixes, then I would suggest
they should be the only such case, as then we would be pretty much in agreement
with the original Java API, and the work effort to change all other such
API cases and their implementations could be quite inconvenient.

> In any event-- we need to decide, we need to document the decision very 
> clearly and we need to make sure our SAX conformance application checks 
> for all of the appropriate cases. Which may involve adding a secondary 
> test suite.

Yes, definitely.

Karl

Re: [Saxdotnet-devel] String.Empty vs. null

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

> One of the things Elliotte mentioned was passing the URI to
> other libraries, instead of checking it. That is what D.Megginson probably
> meant with convenience. So, which libs in .NET would one use?
> And what do they accept? It would be funny if after all the
> discussion they accepted null for an URI.

Elliotte also mentioned that he didn't like to include if (uri == null) 
everywhere-- and that knowing the uri would never be null saved him from 
the clutter.

> I am hesitant to dictate my opinion here. In the end, anything is workable.
> Unfortunately not too much feedback.

So you are a benevolent dictator... I like that...

> If we go with String.Empty for URIs and prefixes, then I would suggest
> they should be the only such case, as then we would be pretty much in 
> agreement
> with the original Java API, and the work effort to change all other such
> API cases and their implementations could be quite inconvenient.

100% agree...

>> In any event-- we need to decide, we need to document the decision 
>> very clearly and we need to make sure our SAX conformance application 
>> checks for all of the appropriate cases. Which may involve adding a 
>> secondary test suite.
> 
> Yes, definitely.

As a side note-- the Java SAX Conformance suite relies on the fact that 
the URI will not be null (as a side affect). Anything that does not do 
so is not "SAX Conformant" according to Elliotte's suite. Now, I think 
that is wrong because it is not legislated-- but every parser he tested 
is conformant on that point... meaning they all pass string.empty and 
not null.

===============
The XmlReader.NamespaceURI has this:

   Property Value
   The namespace URI of the current node; otherwise an empty string.

   Remarks
   This property is relevant to Element and Attribute nodes only.

In XmlDocument.CreateElement:

   namespaceURI
   The namespace URI of the new element (if any). String.Empty and a
   null reference (Nothing in Visual Basic) are equivalent.

In XmlElement.NamespaceURI:

   The namespace URI of this node. If there is no namespace URI, this
   property returns String.Empty.

And finally, XmlNamespaceManager.AddNamespace Method throws an 
ArgumentNullException in the case:

   The value for prefix or uri is a null reference (Nothing in Visual
   Basic).
===========

This all seems pretty compelling... :)

Jeff

Re: [Saxdotnet-devel] String.Empty vs. null

[Karl W. <ka...@wa...>]

Jeff Rafter wrote:
>> One of the things Elliotte mentioned was passing the URI to
>> other libraries, instead of checking it. That is what D.Megginson 
>> probably
>> meant with convenience. So, which libs in .NET would one use?
>> And what do they accept? It would be funny if after all the
>> discussion they accepted null for an URI.

I just checked a few: Uri constructor accepts an empty relative Uri,
but not null. XmlQualifiedName has an empty string for "no namespace".
So I guess its settled, prefix and Uri are emtpy strings in
StartElementHandler and IAttributes when no namespace is present.
Incorrect, but convenient.

> Elliotte also mentioned that he didn't like to include if (uri == null) 
> everywhere-- and that knowing the uri would never be null saved him from 
> the clutter.

Yes, but that only applies if he can just pass it on
and let someone else make the check. If some of *his* code
needs to be executed depending on whether the name is
in a namespace or not, then he needs to check anyway,
and it makes no difference whether you check against null or "".

Just imagine if all those framework classes above would accept
null instead. Our decision would certainly be different.

>> I am hesitant to dictate my opinion here. In the end, anything is 
>> workable.
>> Unfortunately not too much feedback.
> 
> 
> So you are a benevolent dictator... I like that...
> 
>> If we go with String.Empty for URIs and prefixes, then I would suggest
>> they should be the only such case, as then we would be pretty much in 
>> agreement
>> with the original Java API, and the work effort to change all other such
>> API cases and their implementations could be quite inconvenient.
> 
> 
> 100% agree...

OK.
> 
>>> In any event-- we need to decide, we need to document the decision 
>>> very clearly and we need to make sure our SAX conformance application 
>>> checks for all of the appropriate cases. Which may involve adding a 
>>> secondary test suite.
>>
>>
>> Yes, definitely.
> 
> 
> As a side note-- the Java SAX Conformance suite relies on the fact that 
> the URI will not be null (as a side affect). Anything that does not do 
> so is not "SAX Conformant" according to Elliotte's suite. Now, I think 
> that is wrong because it is not legislated-- but every parser he tested 
> is conformant on that point... meaning they all pass string.empty and 
> not null.
> 
> ===============
> The XmlReader.NamespaceURI has this:
> 
>   Property Value
>   The namespace URI of the current node; otherwise an empty string.
> 
>   Remarks
>   This property is relevant to Element and Attribute nodes only.
> 
> In XmlDocument.CreateElement:
> 
>   namespaceURI
>   The namespace URI of the new element (if any). String.Empty and a
>   null reference (Nothing in Visual Basic) are equivalent.
> 
> In XmlElement.NamespaceURI:
> 
>   The namespace URI of this node. If there is no namespace URI, this
>   property returns String.Empty.
> 
> And finally, XmlNamespaceManager.AddNamespace Method throws an 
> ArgumentNullException in the case:
> 
>   The value for prefix or uri is a null reference (Nothing in Visual
>   Basic).
> ===========
> 
> This all seems pretty compelling... :)

Yes, as I said - convenience interacting with the libraries.
It would be interesting if these are new libs adjusting to
a precedent set by SAX originally?

Karl