On Sat, 25 Mar 2006, Anne van Kesteren wrote:

I just noticed that the current text means that this is non-conformant if userInputIsOneThing is true:

var s; if (userInputIsOneThing) { s = 'some random selector'; } else { s = 'some|random selector'; } var node = document.match(s, function(prefix) { if (prefix == 'some') return 'http://example.com'; else return null; });

...which seems bad ("If they don't use namespace prefixes within selectors authors must set nsresolver to null").

Nit-picking -- the paragraph that talks about authoring requirements says that "when authors use namespace prefixes within selectors they must create an object implementing the XPathNSResolver interface" but doesn't require that that object be used in any way (e.g. as an argument to the function). It would be better to require that they pass such an argument.

Also, "In the case of ECMAScript" is probably not what is meant (what is "the case" of ECMAScript?).

I'm not sure about this:

If the nsresolver argument is not of the right type UAs must raise a TYPE_MISMATCH_ERR exception.

...since I would expect the behaviour to depend on the language binding. (In fact, in most typed languages this would be a compile-time error anyway, and in most non-compiled languages there are language-specific rules for handling attempts to invoke methods on non-objects.) In general I would say this applies to any DOM method, and so this draft should not be defining it. Based on the way it is used in DOM3 Core, I would presume that TYPE_MISMATCH_ERR was specifically for arguments of type "any" (DOMUserData). Otherwise, e.g. appendChild() would need to be defined to throw it when passed a non-Node.

One final note -- I saw you added a Security section. Don't say that there is only one problem. When you discover, in 9 years, that there is a second security problem with this interface, you'll look silly if you claimed there was only one. :-)

It's best to just say "History theft is one potential security problem".

Anyway, these are all nit-picking details, which are generally up to the editor to worry about, so I'll stop now. :-)