Re: [xsl] xml:base, resolve-uri and imported xslt files: how to get the importing base url from imported xslt

Subject: Re: [xsl] xml:base, resolve-uri and imported xslt files: how to get the importing base url from imported xslt
From: Abel Braaksma <abel.online@xxxxxxxxx>
Date: Mon, 09 Oct 2006 23:11:47 +0200
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

Current Thread