Re: [selectors-api] Investigating NSResolver Alternatives

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

Bye.

Received on Friday, 15 August 2008 22:26:20 UTC