Re: [XSLT2.0] Consistent Rules on Import Precedence

Re: qt-2004Jan0019-01: [XSLT2.0] Consistent Rules on Import Precedence 
[XSLT2.0] Consistent Rules on Import Precedence, Igor Hersht
igorh@ca.ibm.com (2004-01-11) 

SUGGESTION 1:
3.10.3 Stylesheet Import.
...
"The order of import precedence (lowest first) is D, B, E, C, A.

In general, a declaration with higher import precedence takes precedence
over a declaration with lower import precedence. This is defined in detail
for
each kind of declaration"

It is not clear for me why "In general". Why we cannot have it
as a common rule.I don't understand why sometimes we use import
precedence (e.g. in 9.5 Global Variables and Parameters) sometimes
don't (e.g. in 16.4.1 Defining a Decimal Format). ...


The XSL WG discussed this comment and I was actioned to propose measures
that would tidy up the rules.

I think we have 5 different algorithms:

Algorithm 1: named objects

I believe that we have now achieved consistency for "named objects" where
only one object is applicable (global variables, stylesheet functions, named
templates, imported schemas, character maps, namespace aliases). The rule
here is always that the highest precedence wins, and an error occurs if two
objects have the same precedence and there is no object with higher
precedence.

Algorithm 2: rules

This applies to template rules and to strip-space/preserve-space
declarations. The difference from rule 1 is that if two definitions have the
same precedence, the conflict is resolved using priority.

Algorithm 3: merge definitions

For attribute sets and output definitions we merge multiple definitions.
Conceptually we take these elements as declaring one object for each
"attribute", and apply algorithm 1 at the level of individual attributes.
However these two cases aren't completely consistent because attribute sets
expand recursively.

Algorithm 4: definitions are additive

This rule is applied to xsl:key.

Algorithm 5: no conflicts allowed

This rule is applied to xsl:decimal-format


The most obvious tidying up we can do is to remove algorithm 5, and handle
xsl:decimal-format under algorithm 3. The rules would then be the same as
xsl:output: for each individual attribute, the explicit (non-default) value
of that attribute with highest import precedence is used. This change would
be backwards compatible, since currently any conflict is an error.

Algorithm 4 also seems anomalous. However, it would be difficult to make it
fit any of the other rules precisely, and any such change would be backwards
incompatible.

I don't see any other obvious potential for improving the situation, beyond
the change to xsl:decimal-format. We could try and explain the rationale
more clearly, but I don't think that a spec needs to be an apologia.

Michael Kay

Received on Monday, 15 March 2004 17:25:03 UTC