Re: [selectors-api] NSResolver moving nodes between documents

Bjoern Hoehrmann wrote:
> * Hallvord R. M. Steen wrote:
>> What I've understood: it's proposed that if the custom lookupNamespaceURI  
>> function moves nodes between documents, the implementation trying to use  
>> the NSResolver (may|must) throw an error. I don't see why we can't specify  
>> that unless we specify "when and how many times the resolver is invoked".
> 
> That could be done, but it would have little benefit at a high cost
> (more specification text to read for everyone, more tests to write,
> implementations cannot choose some better behavior, ... versus more
> consistent implementation behavior in a rather hypothetical case of
> incorrect code).
> 
>> "If the custom lookupNamespaceURI function moves nodes between documents,  
>> the implementation trying to use the NSResolver MUST throw an error."
> 
> If there should be a rule for mutations of the document from inside the
> namespace resolver, it should cover all the mutations, not pick some un-
> usual case. Further note that implementations would still differ, e.g.,
> consider the selector
> 
>   a|b > c|d > :not(*|*)
> 
> Some implementations might resolve a,c, others c,a, and yet others none
> of the prefixes because they immediately saw it does not match anything.
> So I would find it preferable, if this needs to be addressed, that the
> prefix resolution is made predictable, so that all mutations from inside
> the resolver become predictable, or that the DOM is locked while the
> query is evaluated, or that all mutations result in an error, not just
> node movements between documents, but I don't think this needs to be de-
> fined at all.

So I might be missing something, but I think we're making this issue a 
lot more complicated than it is. Why not simply specify that the 
querySelector implementation must execute in two steps:

1. Parse selector
2. Walk the DOM and create result using parsed selector.

Step 1 will call the NSResolver, but must not walk the DOM
Step 2 must not call the NSResolver.

This way it is ok if the NSResolver mutates the DOM in any fashion. The 
result returned from the function will simply be based on what the DOM 
looks like after step 1 is done executing.

Yes, we could in theory specify which order the prefixes must be 
resolved using the NSResolver, however I think it would be better to 
state that it's undefined and that resolvers shouldn't rely on this. 
This is effectively the state for XPath and I have never heard of that 
being a problem. I also have a hard time imagining that anyone would 
actually write code that depended on the call ordering.

This should be the easiest solution for spec writers and implementors 
alike. And I don't think users will care either way.

/ Jonas

Received on Monday, 14 April 2008 22:16:31 UTC