[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Types and Context
Hi Gavin, > Not necessarily. I could write an XPath expression that matches > anything with that has a <first> and <last> element inside of a > <name> element, for example. The main difference is really one of > convenience. Personally, if I was *that* worried about convenience, > I'd probably define a "my:type" attribute, set it to "person", and > then match on that. I can see few cases, outside of very > data-centric applications, where the above would be useful. OK. I looked at the DocBook XSLT stylesheets by Norm Walsh to see if I could find an example from a *document-centric* application to persuade you, and very quickly came across the expression: (ancestor::set|ancestor::book|ancestor::chapter|ancestor::appendix |ancestor::preface|ancestor::section|ancestor::simplesect |ancestor::sect1|ancestor::sect2|ancestor::sect3|ancestor::sect4 |ancestor::sect5|ancestor::refsect1|ancestor::refsect2 |ancestor::refsect3|ancestor::qandadiv)[last()]"/> (in common/common.xsl template matching question|answer in label.content mode, used to set the $lparent variable) In a DocBook schema, presumably all of these elements would be of the same type, and the XPath could be simplified to: (ancestor::*[xs:type('docbook:section')])[last()] (or ancestor::*[xs:type('docbook:section')][1] for simplicity) This kind of path isn't uncommon in the DocBook stylesheets. I don't know if Norm has considered adding type attributes to all the DocBook elements to make his life easier... > My main concern with the above is that it is *complicated*. Match > patterns are already fairly expensive/hard to optimize. Adding in > schema support will make them even harder to optimise... especially > in the face of the conflicting incrementality goals for XSLT 2.0. > While some very smart people *will* be able to optimize the match > patterns, it will be beyond the scope of what most people are > capable of, and what most people need. I agree with you. I know it sounds as though I'm arguing for schema support in XSLT/XPath 2.0, but actually I'm only arguing that there is a benefit to it, as an XSLT author, not necessarily that this benefit outweighs the cost to the development of XSLT as a whole. The impact of adding schema awareness to XSLT processors would really depend on the XML Schema processors that are available to provide PSVIs to the XSLT processors. If they're fairly small, have a good API to the PSVI, and are available in lots of languages, then the cost shouldn't be too high. However, I think that's a big *if*, and that concerns me - XSLT has benefited tremendously from having loads of free, open-source processors available, and I'd hate for that to end because they have difficulties implementing schema support. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|