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

Re: [selectors-api] Investigating NSResolver Alternatives

From: Joćo Eiras <joao.eiras@gmail.com>
Date: Fri, 15 Aug 2008 23:25:23 +0100
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>, public-webapps <public-webapps@w3.org>
Message-ID: <op.ufx8klwojz3wb9@mors>

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  

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

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