Tracker Guidelines
Hi, WebApps fans- Many of the specs under development in the WebApps WG use Tracker as their issue- and action-tracking software. Tracker has various states that an issue or action can be in, and the HTML WG formalized those for their own use. [2] I thought they seemed like useful definitions, so I put them in our wiki as a general guideline. [3] If anyone has any comments or questions, please let us know. [1] http://www.w3.org/2008/webapps/track/ [2] http://esw.w3.org/topic/HTML [3] http://www.w3.org/2008/webapps/wiki/Tracker_Guidelines Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
Re: [selectors-api] Investigating NSResolver Alternatives
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. - 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 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. These changes fitted well with the specification because these cases were either undefined or expected implementations to simply throw exceptions. I ask you not to make the same mistakes that were done with the xpath dom api, because nsresolver currently is fairly broken, and not that much useful. Again, I vote for a new lightweight object, and to allow mixing both elements with or without prefixies with null or non null namespace uris. Thank you.
Re: [selectors-api] Investigating NSResolver Alternatives
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.
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.
Say that I wanted to find all elements in the myNS namespace, using a
NSResolver I would do:
doc.querySelectorAll(*, function (pre) {
return pre == ? myNS : null;
});
With your proposed solution I'd have to do
doc.querySelectorAll(*,
document.createElementNS(myNS, dummy));
This looks sort of ok, but still very strange to have to use the dummy
name. However, if i'm using two namespaces in an expression i'm in a
world of pain. Compare
doc.querySelectorAll(a:*, b:*, function (pre) {
return pre == a ? myNS :
pre == b ? myNS2 : null;
});
vs
e = document.createElement(dummy);
e.setAttributeNS(http://www.w3.org/2000/xmlns/;,
xmlns:a, myNS)
e.setAttributeNS(http://www.w3.org/2000/xmlns/;,
xmlns:b, myNS2)
doc.querySelectorAll(a:*, b:*, e);
How many people even know the proper namespace for the xmlns attribute?
Did you?
On top of that we can't really change how DOM-XPath works given that
there are implementations for the spec with pages out there depending on it.
/ Jonas
Re: [selectors-api] Investigating NSResolver Alternatives
João Eiras wrote: On , Jonas Sicking [EMAIL PROTECTED] 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
