This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Future XSLT expansion.


From: "Paul Tchistopolskii" <paul@qub.com>
> > the variable except to pass it back to an extension function. I use this
> > feature to compute running totals efficiently.
>
> ... non-standard and non-portable trick ... Right? As I have been told -
> you should not do that with XSLT.
>
> Specs says that  XSLT Is for processing XML files ( which are node-sets
> by definition ) and that fifth XPath dadatype is not XML, so you should
> not use that thing.
>
> Just kidding - thank you for your letter, I wish things are now a bit more
clear
> for all of us.

Without using an extension function computing running totals in XSLT is an
order n-squared problem. Don't try this on a fifty page report being
formatted to xsl-fo. Without the extension function it will take several
hours to format the report.

The spec does not forbid the opaque variables and I believe it implicitly
allows them.  If you do this: <xsl:variable name="test"
select="xf:myfunction()"/> XSLT is not required to look at the variable; it
is only required to store it. Variables are only checked for type validity
when accessed for use by an internal XSLT function. Later if you call an
extension function with xf:anotherfunction($test) the content of the
variable is passed back without having been typechecked. Doing an
<xsl:value-of select="$test"/> results in an error under XT when $test is of
an unknown type.

I asked to have this explicitly stated in the spec but it never made it in.

Jon Smirl
jonsmirl@mediaone.net




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]