The bit I found non-intuitive (note the past tense now...) was that a
match pattern can be only attribute:: or child:: something that
doesn't get talked about much.
I think the restrictions are just to make the matching process more
tractable, so life a bit easier for XSLT system implementors at a
slight potential complication for stylesheet authors who have to learn
both xpath and xslt patterns (which formally are not xpath at all, it's
not a restructed xpath grammar, it's a separate grammar altogether, that
just looks the same..)
there would be no problem in defining the semantics of
but it would be something else for the syste to check and if it had the
same default priority as match="*" it would probably confuse everyone,
so it's not allowed in patterns, which is no loss really as you can write
which is the same thing, but legal.
Patterns seem to have a very restricted syntax compared to XPath but in
pracyce there have been very few cases where I've wanted to use a syntax
that isn't allowed. It's hard for me to tell if that's because the
patter syntax is sufficiently natural or if its because I have been
assimilated and can't imagine breaking the rules.
The one restriction in XSLT 1 patterns that did hit really hard and was
really unpleasant to work round was the fact you couldn't use global
variables or stylesheet parameters in patterns. Thankfully XSLT2 gets
rid of that restriction.
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>