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
