Thank you Michael, Martin, Chris, and Norm.
I am running my version 3.0 XSLT program from Oxygen which is running Saxon-PE
9.9.1.7
For this template rule:
<xsl:template
match="sid/(sidRunwayTransition|sidCommonRoute|sidEnrouteTransition)">
I get this error message:
Cannot convert the expression
{homCheck(child::element(Q{}sid)/(
(child::element(Q{} sidRunwayTransition) |
(child::element(Q{} sidCommonRoute)) |
(child::element(Q{} sidEnrouteTransition)))} to a
pattern
-----Original Message-----
From: Michael Kay mike(_at_)saxonica(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>
Sent: Thursday, May 19, 2022 10:02 AM
To: xsl-list <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
Subject: [EXT] Re: [xsl] Why can a template rule match on a child of
multipleelements but cannot match on multiple children of an element?
XPath 1.0 expressions (and therefore XSLT 1.0 patterns) only allow a
RelativeLocationPath on the RHS of the "/" operator. A RelativeLocationPath is
essentially a sequence of one or more Steps separated by "/", and a Step
(unless abbreviated) takes the form AxisSpecifier NodeTest Predicate*.
XPath 2.0 generalized the syntax (and semantics) so any expression could appear
on the RHS of the "/" operator (written in parentheses if necessary). XSLT 2.0
however kept the syntax much more restricted for patterns, to ensure efficient
matching: patterns in 2.0 allowed basically only the Step syntax of 1.0 (plus
the ability to call the id() function).
XSLT 3.0 then removed these restrictions to allow a parenthesized expression on
the RHS of "/". It's worth noting that this opened up a very wide range of
possibilities which weren't immediately covered by test cases or by the Saxon
implementation; we're still occasionally finding cases that aren't implemented
or are implemented incorrectly, see for example
https://saxonica.plan.io/issues/5368
https://saxonica.plan.io/issues/4755
As to the "why" question, I don't know why XPath 1.0 imposed the restriction,
though it's fairly obvious why it was subsequently relaxed. One of the design
debates you can have here is paternalism versus orthogolnality. Paternalism
says there's no point writing an expression on the RHS that doesn't depend on
the context item (for example, a literal or a variable reference), so it should
be flagged as an error. Orthogonality says you don't ban things just because
they appear to be useless: for example, you don't make it an error to write $x
+ 0, so why make it an error to write $x / 0 ? And then paternalism says,
anyone who writes $x / 0 has probably made a mistake. There are arguments both
ways, which is why the spec isn't always consistent.
Michael Kay
Saxonica
On 19 May 2022, at 14:22, Roger L Costello costello(_at_)mitre(_dot_)org
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Hi Folks,
Why can I have a template rule like this:
<xsl:template
match="(sidRunwayTransition|sidCommonRoute|sidEnrouteTransition)/supplementalData">
But I cannot have a template rule like this:
<xsl:template
match="sid/(sidRunwayTransition|sidCommonRoute|sidEnrouteTransition)">
/Roger
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--