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
