Lachlan Hunt wrote:
Jonas Sicking wrote:
Bjoern Hoehrmann wrote:
* Anne van Kesteren wrote:
The latest version of the draft (1.14) assumes (in an example) that
you take prefixes from left to right...
x|y:empty > a|b
... In short, defining this would expose implementations details for
no good reason.
I would say that the same holds true for "must not call the resolver
more than once" though. Since the proposed solution doesn't give
deterministic behavior for any given NSResolver anyway, why not simply
say that behavior in this case too is undefined.
I do not think it's wise to explicitly introduce undefined behaviour
where it is not necessary. Although this requirement doesn't make the
NSResolver behaviour any more predictable for the UA, it makes the UA's
behaviour marginally more predictable for the author.
I don't see the point in addressing a minor part of the problem while
leaving much of it unsolved. Besides the problem of order of resolving
the prefixes there's also the issue of calling the NS resolver having
side effects (such as setting global variables). That problem is not
addressed either in the current spec.
I don't actually think poorly written NS resolvers is a big problem at
all. I've never seen an implementation that had this problem and we've
had this interface around for years in the DOM-XPath spec.
So basically it feels like we're making a half-assed attempt at solving
a problem that's not really there and failing at it :)
I'd rather just leave the spec simpler.
/ Jonas
