list4xt : Mailing list for the XT users community.
[list4xt] Re: Naive XSLT [was: Sun XSLT compiler]
Subject: [list4xt] Re: Naive XSLT [was: Sun XSLT compiler]
User: Website From: Leigh Dodds (ldodds@ingenta.com)
Date: 19/06/2000 - 15:02
> > btw. Did anyone attend the presentation on the XSLT Virtual Machine [1]
> > on Friday? Another very interesting session.
>
> I have missed this one...
I may have an article giving an overview of the presentation
available soon, I'll let you know. He speaker added a lot of
comments over what is present in the conference proceedings.
> I don't know if it's what you meant, but I think everyone has his own
> personal reasons of being frustrated by XSLT depending on his prior
> experiences.
>
> To be fair with XSLT, we need to remember that "XSLT is not intended as
> a completely general-purpose XML transformation language" as mentioned
> in the abstract at the very beginning of the recommendation.
I agree; expectations and experience will certainly affect how you
approach a language.
However I think the speaker (who was the Oracle representative on
the XSL WG I believe), was referring to the fact that common
techniques for compiler/VM implementation/design were not applied or
considered during the design of XSLT. He believed that some of the
design decisions were affected by an assumption that a DOM based
model would be used to implement the processor.
He claims that his VM approach will allow mutable variables (i.e. side
effects) without harm.
The compile-time/run-time split in the VM architecture (something which is
not prevalent in current XSLT implementations) also gives greater
control over memory allocation - much of which can be handled on the
stack, and statically allocated, rather than relying on the heap.
> My latest thoughts are that XSLT may lack extensibility and that a more
> complete language might be needed to transform not only the syntax or
> layout of XML documents, but also deal with some of their semantic.
Could you give an example?
(In the same track another speaker talked about using XSLT as a command
processor, using extension functions, for the central core of their
system. It was a interesting idea).
> But it's not XSLT any longer ;=) ... unless maybe if you can plug
> alternative predicate evaluation mechanisms to XPath.
I could see how the ability to evaluate RDF triples might be
useful to implement simple deductive inference. e.g.
socrates is a man, all men are animals, therefore socrates is an animal.
This might have uses in the real world for non-trivial examples.
> Is it XT mark II ?
Its not a mark II from the perspective that we could evolve XT into
a VM. I think you'd have to start from scratch.
One of the reasons I find it interesting is that the speaker believed
that if the input and output formats are known in advance then the
XSLT compiler can further optimise the bytecode, to the point
that the transformation could be approached serially. Allowing
SAX to be used as an input and output, and removing the necessity
to build a DOM.
Cheers,
L.
--
Leigh Dodds, Systems Architect | "Pluralitas non est ponenda
http://weblogs.userland.com/eclectic | sine necessitates"
http://www.xml.com/pub/xmldeviant | -- William of Ockham
--
Mailing list for the XT users community. (http://waukeestatebank.com)
(mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe)
Archive générée par hypermail 2b28 le 06/11/2001 - 11:46 CET
webmaster@4xt.org
|