W3C home > Mailing lists > Public > xsl-editors@w3.org > October to December 1999

Re: Variable references and import precedence

From: James Clark <jjc@jclark.com>
Date: Sat, 11 Dec 1999 10:49:56 +0700
Message-ID: <3851C9E3.919988FC@jclark.com>
To: Kay Michael <Michael.Kay@icl.com>
CC: "'xsl-editors@w3.org'" <xsl-editors@w3.org>
Kay Michael wrote:

> Given a variable reference, there is a need to identify the relevant
> variable-binding element. I think it's pretty obvious what the spec intends
> here, but I don't think the rules are explicitly spelled out.
> - it doesn't explicitly say that when a local variable shadows a global
> variable with the same name, the local variable will be the one that is used

I think this is covered by:

"For any use of these variable-binding elements, there is a region
of the stylesheet tree within which the binding is visible; within
this region, any binding of the variable that was visible on the
variable-binding element itself is hidden.  Thus, only the innermost
binding of a variable is visible."

(This is rather overly general given that shadowing of local variables
is prohibited.)

> - it doesn't explicitly say that where there are several global variables
> with different import precedence, the one with highest precedence is chosen.

That is a bug.

> Unless I've missed something, of course.
> Just really intended as a note for the next edition.
> Incidentally, I think the way in which each top-level element is treated
> differently as regards import precedence is very confusing to users. There
> seems little logic as to the cases where duplication is an error that must
> be reported, the cases where it is an error that the implementor is allowed
> to recover from (every such choice given to the implementor creates a
> portability problem for users), and the cases where it is not an error at
> all.

It may seem that there is little logic, but careful consideration was
given to this.  One key factor is whether the error is detectable
independently of any input document.  If it is, then no recovery option
is provided.

> A useful feature in version 2 would be to put the decision between
> strict and lenient error handling in the hands of the user rather than the
> implementor.

I believe this is a feature that should be provided by implementations
not the stylesheet language.

Received on Saturday, 11 December 1999 00:18:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:17 UTC