Re: [selectors-api] Proposal to Drop NSResolver from Selectors API v1

On May 12, 2008, at 9:38 AM, Bjoern Hoehrmann wrote:

> * Maciej Stachowiak wrote:
>>> You can just use `function(p) { return namespaces[p]; }` then.
>>
>> Sure, but there's no actual need to allow running arbitrary code and
>> all the risks that creates/
>
> Which is no risks at all. You can simply parse the selector for the  
> pre-
> fixes, resolve all the distinct ones and the default namespace, then  
> use
> the gathered information in the selection process. That's no different
> than the calling script doing the same, filling a table in the  
> process,
> and passing the table. If you want to do something more clever, you  
> may
> also cleverly shoot yourself in the foot, yes.

It is better API design to remove the possibility of some categories  
of errors.

> (There are other problems with using an object like the one you  
> propose,
> like being unable to specify a default namespace, unless you introduce
> some kind of magic prefix representing the default namespace;  
> ultimately
> you don't gain much; you could also just accept a simple string in the
> form "prefix1=ns1 prefix2=ns2 ..." like MSXML does for XPath, but  
> there
> isn't really a problem worth solving with the resolver function.)

I'm convinced. I like the string better than my proposal. It removes  
the need to specify anything regarding setters or other language  
bindings.

Using a function does not seem to provide any value over providing the  
data in some trivial static form, and at least some complications. It  
seems like the only reason we have that design in the spec is inertia.  
Are you willing to argue that it is better than other solutions on the  
merits, for any reason other than it happens to be what is already in  
the draft spec?

Regards,
Maciej

Received on Monday, 12 May 2008 17:28:32 UTC