- From: Werner Donné <werner.donne@re.be>
- Date: Fri, 15 Apr 2005 16:43:57 +0200
- To: www-svg@w3.org
Hi, An open issue is still whether XPath or CSS should be used in the "includes" attribute of the "content" element. I would use XPath, because it is more general. I also see no reason to limit it to some subset of XPath or to leave out namespaces. The former because processing full XPath cannot be an issue anymore. The latter because namespaces are what makes XML modular. Dropping namespaces is a severe limitation for the documents and achieves nothing. Simplicity for the user is not a good argument for not using XPath, because an XPath expression can be as simple as "a/b/c". Offering simplicity should not imply limitations for the expert user. I think that is what the abbreviated XPath syntax is for. It is true that the CSS selector "a + b" is much easier to write than "b[preceding-sibling::*[1][name() = 'a']" or "a/following-sibling::*[1][name() = 'b']". If the working group thinks there are users who know what "a + b" means and who can't cope with the corresponding XPath syntax, it is perhaps an option to allow CSS selectors as well as XPath. In both cases XML fragments are addressed starting from a context node and in both cases a node set is returned. With CSS this set will contain only elements, while for XPath other node types are possible as well. The latter shows the generality of XPath, because it is possible to grab the mixed content of some descendant element. If only CSS selectors are available, replacement with mixed content coming from the document is only possible if no includes attribute is present, implying the complete contents of the context node is taken. Best regards, Werner. -- Werner Donné -- Re BVBA Engelbeekstraat 8 B-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be
Received on Friday, 15 April 2005 14:44:09 UTC