Re: [Saxdotnet-devel] String.Empty vs. null
Brought to you by:
jeffrafter,
kwaclaw
From: Karl W. <ka...@wa...> - 2005-01-13 22:55:07
|
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 |