The
"dynamism" that is needed to build certain kinds of processing logic into XSLT
almost demands some type of on-the-fly compilation. I can see two ways to
achieve the same "end game":
1)
Built into the XSL processor itself
2)
Built external to the XSL processor by manipulation of the structure/content of
the XSL document itself, and the "mutated" XSL is then processed normally by the
XSL processor
On an
application basis, #2 is certainly viable, however, it does create a
"non-standard" or application-specific approach to the problem. One
thought would be a hybrid approach that provided some type of entity/parameter
replacement above and beyond standard XSL parameters. The XSL processor
could generically deal with this entity/parameter parsing/replacement, and
presence of such things would flag the XSL processor that a recompilation was
required.
I
think we'll lean towards massaging the XSL being fed into the XSLTC engine,
though I'll admit we're still unclear as to some of the "under the hood"
dynamics of how to optimize this (e.g. caching and re-using the compiled state,
etc.) and the implications of "one-off" XSLTC compilations versus interpretive
processing (e.g. is the compile step more costly in terms of performance than
interpretive execution?).
In any case, the
need to dynamic XSL is indeed a very real one. I welcome your thoughts and
ideas on how to meet the challenge!
Rick Bullotta
CTO
Lighthammer Software (http://www.lighthammer.com)
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 28, 2003 6:30 PM
To: [EMAIL PROTECTED]
Subject: RE: XSLT and XPath 2.0 development
You can still implement dynamic evaluation in a compiled environment... it just means a) the compiler needs to be available as part of the runtime, and b) we would need to set these things up to compile fragments.
But, I guess what you really loose is that I've seen some user extensions that mutate the stylesheet at runtime. This becomes a harder proposition. My knee-jerk is that the world could live without this, though I'm not so sure when I think of some editing environments.
Sigh.
-scott
"Rick Bullotta" <[EMAIL PROTECTED]> wrote on 08/28/2003 10:45:20 AM:
> A few thoughts:
>
> Our application work requires considerable usage of extension functions,
> notably some of the Xalan/EXSLT dynamic functions (evaluate, min, and
> max), which appear to be "structurally unsupportable" in XSLTC. As
> such, we would certainly be interested in seeing Xpath 2.0 support on
> Xalan-J interpretive. As a use case, example, suppose an XML document
> contains rows and columns of data in a format such as:
>
......
