Reply from Mozilla on null strings

Curt Arnold wrote:
> 
> Background:
> 
> There has been a little running discussion on www-dom@w3.org on an errata to
> the DOM Level 1 specification DOMImplemention.hasFeature() method that
> also appears to apply to the Level 2's Document.createElementNS and other
> *NS methods.
> 
> Basically, behavior was specified when a string argument was "unspecified"
> (for hasFeature) or "null" for the createElementNS and similar.
> 
> For example:  For most, if not all, Java XML DOM implementations:
> 
> ((DOMImplementation) impl).hasFeature("XML",null);
> 
> will return true if the implementation supports any version of the XML
> specification.  The null argument acting as a wild-card.
> 
> This will not work on either IE or Mozilla/NN 6 ECMAScript.
> 
> In IE, the COM interface definition is specified as a BSTR (basically a
> wchar_t*) and the text explicitly specifies the behavior when the BSTR is 0.
> However, the COM variant coercsion code (or so I speculate) will not
> convert a variant null (VT_NULL) to a BSTR and throws an exception
> if you try hasFeature("XML",null).
> 
> The corresponding Mozilla code
> (http://lxr.mozilla.org/seamonkey/source/content/base/src/nsGenericElement.c
> pp#880)
> is passed an nsReadableString& and checks for a zero length string and known
> versions strings, but no apparent check for a null string, so:
> 
> document.implementation.hasFeature("XML","") returns true
> 
> but
> 
> document.implementation.hasFeature("XML",null) returns false
> 
> I was a little surprised that the second call returned false which hints
> that it actually
> made it to the hasFeature method instead of failing on a preliminary
> coerscion step
> and throwning an exception.
> 
> ----
> 
> Now for the question:
> 
> 1.  (Serious question)
> 
> Does nsReadableString has a state that represents an null string distinct
> from a zero length string?
> 
> My guess from the code is that it does not, but I need to confirm that.
> If it does, how do you check if a string is null.
> 
> I expect that you could represent both null and a string using a variant
> type, however changing the spec to conform to the limitations of the string
> classes and deployed behavior is more practical than forcing a
> change of the implementation.

shaver@mozilla.org, scc@mozilla.org, and jst@netscape.com are
working on representing null in these classes to make the DOM do
the Right Thing.

http://bugzilla.mozilla.org/show_bug.cgi?id=69468

> 
> 2. (More a curiousity question)
> 
> Why does document.implementation.hasFeature("XML",null) return false instead
> of
> throwing an exception on a coerscion of null to a string?  Does control ever
> reach nsGenericElement::InternalIsSupported()?  If so, how could it be
> written
> to return true?

The DOM newsgroup is really the right place to discuss this stuff
and perhaps get answers.

John.