Re: Types and Context

[Jeni Tennison <mail@jenitennison.com>]

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/