Re: [Issues] Call for issues to put to the DOM WG / Open issues

Here are a couple of issues, I don't have all the details on but it would at
least be good to get the general feeling of the WG.

---------
Issue 1: ECMAScript and null strings:

This has already partial been dealt with in the errata on
DOMImplementation.hasFeature.  Null is not in the value space of
ECMAScript's string class, C++ STL's std::basic_string and I'm sure other
languages.

I pulled the following list of methods from DOM L2 that have null somewhere
in the description of a DOMString parameter using an XSLT transform.

DOMImplementation.hasFeature() version parameter
Node.nodeValue
Node.isSupported() version parameter
Node.namespaceURI
Node.prefix
Node.localName
Notation.publicId
Notation.systemId
Entity.publicId
Entity.systemId
Entity.notationName
StyleSheet.href
MediaList.item return value
ViewCSS.getComputedStyle() pseudoElt param
DocumentCSS.getOverrideStyle() pseudoElt param
HTMLDocument.domain

Since the Netscape/Mozilla nsString can not represent a null value and a few
tests on MSXML indicate that it returns a zero length string for attributes
such as Notation.publicId, it appears that the deployed ECMAScript DOM
implementations have effectively translating the null in the context of
DOMStrings to an empty string.

It will probably take some verbal gymnastics (maybe introducing a nullString
concept which is mapped to either null or "" depending on the binding), but
I think that there needs to be a solutions something like:

All implementations should be encouraged to process "" equivalently to null
for parameters and when setting attributes the attributes listed.  So
hasFeature("XML","") and hasFeature("XML",null) should both work on a Java
binding.

All return values and attribute retrievals mentioned should return null in
Java bindings (and other bindings where null is in the value space of the
DOMString) and return an empty string in ECMAScript (and other bindings
where null is not in the value space).

---------------

systemId attribute (DocumentType, Entity, Notation)

At least one implementation returns an absolute URL instead of the relative
URL that is in the source document for Notation.systemId.  Since the file
may have been moved or cached, absolutizing the URL based on the current
location may provide erroneous location.  The submitted NIST test attempted
to compensate for this behavior, however I have removed that URL cracking
code since it imagined string manipulations that weren't in DOMTSML and the
test in the CVS currently only accepts the literal contents of the XML file.

Received on Wednesday, 22 August 2001 11:53:54 UTC