Re: [selectors-api] Proposal to Drop NSResolver from Selectors API v1

Maciej Stachowiak wrote:
> On May 12, 2008, at 12:44 AM, Jonas Sicking wrote:
>> Lachlan Hunt wrote:
>>> In relation to the NSResolver, the major issue is that I need to 
>>> define how to handle hostile NSResolvers and deal with unexpected DOM 
>>> modifications.
>>
>> I don't actually think there is a lot to do spec-wise here. IMHO all 
>> that is needed is to say something like:
>>
>> "An implementation encouraged to deal with hostile NSResolvers and are 
>> allowed to throw an exception if such resolvers are detected".
> 
> Having considered it for some time, I think running arbitrary code to 
> resolve namespace prefixes is a bad approach.
> 
> A function is not a particularly convenient way to specify a namespace 
> mapping, and it creates these error handling issues as well as causing 
> problems with case (in)sensitivity. Even though NSResolver is what XPath 
> uses, wouldn't it be simpler to just accept an object that provides the 
> relevant namespace mappings? I originally thought that this could be a 
> JSON-style JavaScript object, but it seems to me that a DOM node would 
> actually work just as well. Most of the time, you want to use the 
> namespace prefixes in effect for the root element, and if not, then it 
> is pretty simple to construct a DOM node with all the right xmlns 
> declarations. I think this would be better than copying the bad 
> NSResolver design from XPath.

This is possible, since the spec is already compatible with 
Node.lookupNamespaceURI().  I think it would just require that a Node be 
passed and ignore any other type of object.  But, there are a few 
problems with the approach.

If scripts were to use elements from the actual document to obtain 
prefixes, it ties the script to that document and others that use the 
same prefixes only.  Scripts intended for reuse elsewhere would need to 
construct their own node and set all necessary namespaces.

The code for creating that is, unfortunately, a little complex, and so 
it is not ideal.

var nsresolver = 
document.createElementNS("http://www.w3.org/1999/xhtml", "div");
nsresolver.setAttributeNS("http://www.w3.org/2000/xmlns/", "xmlns",
                           "http://www.w3.org/1999/xhtml");
nsresolver.setAttributeNS("http://www.w3.org/2000/xmlns/", "xmlns:svg",
                           "http://www.w3.org/2000/svg");
nsresolver.setAttributeNS("http://www.w3.org/2000/, "xmlns:math",
                           "http://www.w3.org/1998/Math/MathML/");

The Namespace URI Lookup algorithm [1] seems to indicate that the 
element needs to have an expicit xmlns attribute set in order to get the 
default namespace from its value, instead of just obtaining it from the 
element's actual namespace.  But the problem is, implementations don't 
agree with each other.  They also don't agree on what to return when the 
paramter is null, undefined or "".

So if we were to go with this solution, the interoperability issues 
would have to be resolved, which would mostly likely mean fixing the DOM 
3 Core spec first.  But that still doesn't solve the complexity issue.

>>> I decided to retain the NSResolver in the spec for now.  However, I 
>>> have made support for it optional and defined that if it isn't 
>>> supported, a NOT_SUPPORTED_ERR exception must be raised if an 
>>> NSResolver is passed.
> 
> I'm not very happy with this because it precludes coming up with a 
> better solution than NSResolver.

If we can find an alternative solution that we can all agree on, I'd be 
happy to replace the NSResolver with it.

[1] 
http://www.w3.org/TR/DOM-Level-3-Core/namespaces-algorithms.html#lookupNamespaceURIAlgo
-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Monday, 12 May 2008 13:18:37 UTC