Re: [selectors-api] Investigating NSResolver Alternatives

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