- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 20 Apr 2007 15:52:41 -0700
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- CC: Anne van Kesteren <annevk@opera.com>, "Web APIs WG (public)" <public-webapi@w3.org>
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 and requires (in prose) that you reuse >> the result for each unique (after lowercasing) prefix. > > I think the draft should only define that implementations must not call > the resolver more than once for any prefix; whether the implementation > looks up a specific prefix at all or in which order it does so should be > up to the implementation. As an example, > > x|y:empty > a|b > > would match no elements, the implementation might notice that before it > cares about the prefixes, and if it does not, it could reasonably start > evaluating the selector from either side. 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.e. the behavior of the following NSResolver var N = 0; function resolver(prefix) { return ['http://myns1.org', 'http://myns2.org][N++]; } is undefined for "x|y:empty > a|b", so why couldn't it be for "x|y:empty > x|b". I think we should say that the resolver should return the same value for a given prefix, and that it is not defined how many times or in which order the UA calls lookupNamespaceURI. / Jonas
Received on Friday, 20 April 2007 22:54:34 UTC