Re: Doubts regarding XSL and DOM

[keshlam@xxxxxxxxxx]

>But what if I want to "traverse" my XML source tree from XSL apart from
>"querying" it?

Depends on what you mean by "traverse". Might help if you provided a
concrete example.

If you mean find another node of the tree relative to this one and run an
XSL processing template on it, you issue another query. The query language
should be rich enough to handle this.

If you mean you want to do something more complicated than XSL's query
language and templates will support, you either don't use XSL, or you use
the escape mechanisms that may (or may not) be designed into XSL. Early
versions of XSL did have some support for Ecmascript, which was given
DOM-like read-only access into the model... The current spec doesn't have
that feature, but I get the impression that it hasn't yet been ruled out
for future versions.

>a) XSL needs to be more than just a query language.

It is. It's a template/transformation language.

>b) An object model would be needed to enable the traversal

Not if the queries can express everything that the templates need to be
able to find and the templates can express everything that needs to be done
to generate the output XML.
Note that "everything" doesn't mean solve every possible transformation
problem. XSL isn't a fully general programming language and isn't intended
to be. 'Way back when, someone stated that XSL ought to be able to handle
90% of the likely transformations, and I think that's a realistic goal.
There will always be some tasks for which you'll use hand-coded processing
-- either via a scripting mechanism within XSL, _if_ that's added, or by
stepping back and building your own program that operates directly on the
DOM.

______________________________________
Joe Kesselman  / IBM Research
Unless stated otherwise, all opinions are solely those of the author.



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