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