W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [selectors-api] Investigating NSResolver Alternatives

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 15 Aug 2008 15:53:50 -0700
Message-ID: <48A608FE.10804@sicking.cc>
To: Joćo Eiras <joao.eiras@gmail.com>
CC: Lachlan Hunt <lachlan.hunt@lachy.id.au>, public-webapps <public-webapps@w3.org>

Joćo Eiras wrote:
> On , Jonas Sicking <jonas@sicking.cc> wrote:
>> Joćo Eiras wrote:
>>>  Hi !
>>>  I vote for having a new light weight object to completely replace 
>>> the current NSResolver, and then apply it to other DOM specs namely 
>>> the XPath DOM.
>>>  I had some of the problems we're discussing with the XPath DOM API, 
>>> and obviously the same apply here.
>>> I exposed my problems at the dom mailing list, but my comments were 
>>> dismissed completely
>>> http://lists.w3.org/Archives/Public/www-dom/2007OctDec/0002.html
>>>  The problems I outlineed with NSResolver are summarized to the 
>>> following:
>>>  - a element with no prefix is assumed to be
>>>    in the namespace with null uri. You can't
>>>    change this behavior.
>> This is not true. We can just define that unprefixed names call into 
>> the NSResolver with an empty string, and whatever the NSResolver 
>> returns will be used as prefix.
>>>  - a element with a prefix MUST be in a
>>>    namespace with non null namespace uri, else
>>>    returning empty string from lookupNamespaceURI
>>>    results in NAMESPACE_ERR being thrown
>> Again, this is not true. We can just define that returning the empty 
>> string means to use the null namespace.
>> null is the value that's supposed to be returned when no namespace is 
>> found and NAMESPACE_ERR should be thrown.
>> Even the resolver returned from createNSResolver is horribly 
>> underdefined and so we could make it follow the above rules without 
>> breaking any specs.
> You misread. That was the list of issues I outlined on the dom mailing 
> list, back in 2007.
> Of course we can workaround them, and we should.
>>> I proposed the following changes:
>>>  - a element with no prefix would result in
>>>    lookupNamespaceURI being called with the empty
>>>    string, and the resolver could return a default
>>>    namespace, or return null (or empty string) to
>>>    imply the null namespace
>>>  - a element with prefix would result in
>>>    lookupNamespaceURI being called with the prefix
>>>    and the function could either return null
>>>    (or empty string) to imply the null namespace,
>>>    or it could return a fully qualified uri.
>> Having to create an element whenever you want to resolve some custom 
>> namespaces seems like a horrible hack, and awefully complicated to use.
> Having what ? Since when did I suggest creating elements ?
> That list of suggestions were about chaging NSResolver behavior.

Doh! I got to the "a element" part and then misread the rest with faulty 
assumptions. My bad. I agree with the above.

> You may go to 
> http://lists.w3.org/Archives/Public/www-dom/2007OctDec/0002.html for 
> code samples.

Unfortunately I don't think we can change how XPath parses things since 
there is already code out there that might rely on the current behavior. 
Might be worth looking into though.

/ Jonas
Received on Friday, 15 August 2008 22:57:14 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC