[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: xml:base, resolve-uri and imported xslt files: how

Subject: Re: 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
Re:  xml:base
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,

-- Abel Braaksma

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.