- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Fri, 10 Aug 2007 22:08:43 +0100
- To: Vasil Rangelov <boen.robot@gmail.com>
- CC: public-xml-processing-model-comments@w3.org
Hi Vasil, > Still, there's no reason not to allow all sorts of nodes (text nodes in > particular) be matched, is there? And I still don't see why should an error > be raised if no node(s) are matched. I think that the wording's a bit off: what it's really trying to say is that it's an error if the pattern *might* match something other than an element or attribute (or possibly if it *does* match something other than an element or attribute). I certainly agree that the current wording implies that it's an error if nothing gets matched, and that that shouldn't raise an error. I'm torn on allowing other kinds of nodes. I think the argument for the status quo is probably that only elements and attributes can/should hold data: that it would be bad practice to have a markup language in which you'd *need* to match text nodes, comments or PIs. For example, for matching text nodes to be useful, you'd need a design like: <links>index.html<sep />archive.html</links> which isn't something we'd want to encourage. Also, we're never going to be able to do *every* kind of absolutisation with this step, so we should perhaps only focus on the really common ones. On the other hand, I generally believe in giving people tools even if they might use them incorrectly. And I've certainly used PIs that hold URIs, so I have some sympathy with providing support for all kinds of nodes. Hopefully Norm will add it to the agenda and we'll see what the rest of the WG thinks. Cheers, Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Friday, 10 August 2007 21:09:04 UTC