Michael Kay wrote:
This seems to only apply to the binding, not to the other
attributes of a parameter. But this import precedence does
apply, when going from required=no to required=yes (???).
We looked at doing something along these lines and it got too complicated.
During the standardization process, you mean? I see. I was trying to
understand what happened when the predicate "param is required"
overrules, no matter the precedence rules, all equally named parameter
declaration. The fact that it still happens in Saxon (not sure of
others), does that mean that it is actually heritage behavior of an
older version of the spec, and thus should better not be there?
If there are two params (or variables, or a mixture) with the same name and
different precedences, all but one of the declarations are ignored. It's as
if the others weren't there. They can even have completely unrelated types.
As I understand it, I can completely redeclare something, better yet, I
can either completely redeclare something, or not redeclare something at
all. Which can come in very handy, now that I know of it in more detail.
But this does not fit the actual behavior (again, with Saxon, not sure
of others) of the processor not respecting the redeclaration of the
'required' attribute of a global parameter.
High precedence declaration (stylesheet A:
<xsl:param name="redefine-me" required="no" select=" ' some value ' " />
Low precedence declaration (stylesheet B):
<xsl:param name="redefine-me" required="yes" />
Result of running this from any stylesheet A, where A is the main
stylesheet and A includes stylesheet B, the expected behavior is (if I
understand everything from this thread, you and the specs correctly)
that the parameter 'redefine-me' will receive the value 'some value' and
not throw any error.
In fact, it throws the error: "E No value supplied for required
parameter redefine-me]". Imho, this is not correct, a processor should
not throw this error, because the parameter has been given a different
definition with a default value on a higher precedence level.
Turning it the other way around (B includes A) will indeed throw the
error, but this time it is the correct error and the behavior is expected.
Though this might sound like hair-splitting in the small corners of the
specs, I actually find it a pretty useful way where you can declare
module-level parameters, which *must* be overridden by either an
including/importing higher precedence stylesheet, or must be set by the
processor. This gives quite some extra power to module designers, I think.
Is the above indeed a bug, or am I misinterpreting something?
Thanks Michael, for all your precious time,
Cheers,
-- Abel Braaksma