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

Re: [Erratum] core-14. DOMImplementation.hasFeature (Re: hasFeature with "unspecified" version)

From: Curt Arnold <carnold@houston.rr.com>
Date: Thu, 12 Jul 2001 11:35:33 -0500
Message-ID: <000701c10af0$ac45f820$7600a8c0@CurtMicron>
To: <www-dom@w3.org>
Just to refresh on the back ground for those who tuned in.  The impetus for
the initial question was that the NIST tests had code like:

boolean hasFeature = impl.hasFeature("XML","");

but didn't test:

boolean hasFeature = impl.hasFeature("XML",null);

I can't justify that the first as a valid test based on the original text,
"" isn't unspecified, it is an empty string.

I think that the majority of Java developers would look at the second form
and the spec and say it should return true if the processor supports any
version of XML.  However, I believe at least one processor threw an
exception when passed a null.

If the NIST test form and only the NIST test form is correct, then
"unspecified" should be "empty string"

MSXML 3.0's documentation for IXMLDOMImplement.hasFeature (
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk30/ht
m/xmmthhasfeature.asp) and System.Xml.XmlImplementation
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html
/frlrfsystemxmlxmlimplementationclasshasfeaturetopic.asp)
interpreted unspecified == null

>Version number to test, or, if Null, tests for implementation of the
feature
>in any version. In Level 1, "1.0" is the only valid version value.

I think an errata is necessary because different people have looked at that
statement and come up with different interpretations.

So the options are:

1. Change "unspecified" to "empty string".  The NIST test stands, and the
behavior using null is unspecified.

2. Change "unspecified" to "null".  Behavior using empty string is
unspecified.

3. Change "unspecified" to "null or empty string".  The NIST test stands
(but an additional test should be added) and the behavior using null is
specified.

4. Change "unspecified" to "undefined, null or empty string" or "undefined
or null"

This would definitely be the most desireable from a usage standpoint and
might possibly reflect the behavior of deployed ECMAScript implementations.
I will try to check the MSXML behavior when I finally get to the office.  If
someone could quickly check Netscape 6/Mozilla, I'd be grateful.

Basically, you would want to results of:

impl.hasFeature("XML","1.0");
impl.hasFeature("XML","");
impl.hasFeature("XML",null);
impl.hasFeature("XML",undefined);
impl.hasFeature("XML");

If both browsers return true for all the cases, or for all the cases except
"", then I'd change it to "undefined, null, or empty string".

If Microsoft fails the last two, then "undefined" would not be acceptible.
The hasFeature method is defined as a BSTR which doesn't have a distinct
value for "undefined".  JScript will either coerce undefined to a null BSTR
or throws an exception before it invokes the implementation.  If it throws
an exception on the coercsion, then it would require a change of their
version parameter to a VARIANT to prevent to coercsion and that would be
unacceptibly distruptive.

I'll try to get the results for at least the MSXML tests within the hour.
Received on Thursday, 12 July 2001 12:34:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:49 GMT