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: Karen Lease (klease@club-internet.fr)
Date: 20/06/2000 - 00:08
Leigh Dodds wrote (in reply to Eric van der Vlist in reply to Leigh
Dodds):
>
> > > 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.
>
K: I was there and took some notes too. I found it a very interesting
(though extremely technical) presentation.
> > 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.
K: personally I always compare it with DSSSL and it usually loses. It
was much more elegant to write and (in the absence of a good XSL editor)
easier to read. This talk made me think about jade (J. Clark's DSSSL
implementation, now managed as OpenJade). Since DSSSL is based on
Scheme, the interpreter is closer to the architecture described in the
talk. The jade implementation doesn't get down to such a low level
however. And there is still a full "grove" (the SGML/HyTime/DSSSL
superset of the DOM).
> 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.
K: Even XT uses a kind of DOM. But the om package is a very light-weight
DOM, really a mini-grove implementation. I read once that J. Clark had
not used DOM because he didn't like it, probably because it is difficult
to make an efficient one. Maybe this is one of the reasons for XT's
speed.
> 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.
K: Yes, I found that an interesting remark. Actually, I interpreted it
to mean the input schema or DTD. If we assume the document conforms to a
schema, then we will should be able to confine some processing to
subtrees. For example, if we have some rules for an "abstract" element
and the schema says there is only one at the beginning of the document,
we don't need to see the whole tree to apply this rule. But this sounds
like MAJOR work.
> Cheers,
>
> L.
Best regards,
Karen Lease, SGML/C++ hacker more or less coverted to XML/Java...
email:klease@club-internet.fr
--
Mailing list for the XT users community. (http://wblawlibrary.org)
(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
|