RE: [XSLT2.0] Stylesheet Import

> 
> 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). I think it should be explained. If there is 
> no any technical reason to have it just "In general" , we 
> should have common rules - we should use import precedence 
> (not using import precedence as a "common rule" makes no 
> sense because it would have the same functionality as xsl:include).
> 

Personal response: I've struggled with these inconsistencies for a
while. We're limited in what we can do about them because of backwards
compatibility.

I think we could possibly reduce it to two categories: 

(a) highest precedence wins. This applies to templates, variables,
params, strip-space, namespace-alias, import-schema. We have already
aligned the rules for how conflicts are dealt with. For named objects a
conflict is a static error, for rules (templates, strip-space) it's a
dynamic error.

(b) merge all definitions. This applies to keys, attribute sets, decimal
formats, output definitions. Currently each of these behaves a bit
differently. With keys there are never any conflicts. With attribute
sets each attribute is subject to import precedence. With output
definitions each output property is subject to import precedence.
Decimal formats do stand out as the exception, and I can't see a good
reason why they shouldn't be aligned with xsl:output, using the import
precedence of each property separately rather than making conflicting
definitions an error.

Michael Kay

Received on Tuesday, 13 January 2004 14:49:21 UTC