W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2001

Re: Namespace resolution in L3 Core and XPath (was Full infoset support for DOM 3 Core)

From: Curt Arnold <carnold@houston.rr.com>
Date: Fri, 7 Sep 2001 17:42:44 -0500
Message-ID: <002501c137ee$68f3d940$a800a8c0@CurtMicron>
To: <www-dom@w3.org>
> If I am not mistaken, ECMAScript implementations which substitute ""
> where the spec says null are broken.  That does not preclude other
> bindings from making that substitution where required, but the
> ECMAScript binding does not require it.  Log a bug against mozilla and
> vote for it.  I was told it is clearly broken behavior.

There is already a pretty substantial discussion on this in bug 69468,
http://bugzilla.mozilla.org/show_bug.cgi?id=69468   The last comment was
that support for null DOMStrings didn't make the cutoff for 0.9.4.  I assume
that after this work is complete, that DOM functions that should return null
DOMString's and those that take null strings are parameters will work per
spec and like the Java binding.

Microsoft MSXML is a little more complicated.  Most DOM 1 routines that
should return null DOMString's (Node.nodeValue in particular) do, however
the publicId and systemId attributes of Entity and Notations will return ""
when the corresponding Id is not present.

DOM routines that should take null strings as an parameter (for example,
hasFeature() or any of the *NS methods) have problems from both Mozilla and
MSXML from JavaScript and Visual Basic.  I would assume the problem will be
fixed for Mozilla with the resolution of bug 69468.  However, the issue with
null string parameters from Visual Basic and JavaScript could be avoided by
defining the parameter as a VARIANT instead of a BSTR.  Null BSTR's can be
passed null from C++, however attempting to pass null to a BSTR argument
from VB or JScript will result in a type mismatch.

So it looks like ECMAScript bindings can be brought into line without much
more pain.

There are still other non-standard bindings where the obvious DOMString (for
example, C++ STL str::basic_string) can't represent null strings.  So
having, for example, having lookupNamespacePrefix() return "#default" if the
default namespace is matched and null if not matched would reduce the pain
on those bindings.
Received on Friday, 7 September 2001 18:43:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:09 UTC