|
The first impression that I had when seeing the SVG path notation was alarm, as it did seem to introduce some complexity in the development (such as, for instance, animating a particular point in an SVG object), yet after I had a chance to think about it I realized that this particular form actually did offer some of the best benefits, and it was something that could readily be parsed in SVG with just a shade more work than otherwise.
This has got me to thinking about the other "small" languages that are being subtly introduced into the XML canon. Regular Expressions first appeared in the XSLT WD, but disappeared before the Recommendation became finalized. They have resurfaced in XML Schema, and personally I think that they make a great deal of sense to appear within XPath notation as well. Being able to write an XSL expression such as
<xsl:apply-templates select="//phone[. ^= /^(?$areaCode(?[-\s]?\d3-\d4/]"/>
would make for far more sophisticate matches than what currently exists (contains(.,$areaCode) would match as well, but there's no way that you could ascertain that the match was on the area code, the exchange or as a part of the sequence of the local code).
The XML syntax proposal for XML Query is just plain ugly, and demonstrates quite well why working with alternative syntaxes have their place -- XPath does not in fact lend itself to being described in XML terms.
Indeed, I think one of the more intriguing aspects of XML Query that should ultimately be incorporated into XSLT 2.0 is the notion of creating XPath functions via an XML notation -- having a procedural notation for XSLT named templates, for instance, would make it easier to create sophisticated interrim XML that could be fed directly into an XPath expression without the ugly (and non-conformant) use of node-set() and multiple variables.
-- Kurt Cagle
-- Author, XML Developers Handbook
|
Previous Message
