- From: Joćo Eiras <joao.eiras@gmail.com>
- Date: Fri, 15 Aug 2008 22:03:08 +0100
- To: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>, public-webapps <public-webapps@w3.org>
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.
Received on Friday, 15 August 2008 21:04:03 UTC