Re: The XSL-List Digest V1 #192

[keshlam@xxxxxxxxxx]

>It's the "document transformation" part that XSL achieves that makes me
feel
>that some kind of an object model (DOM in my case) is needed. The reason
>being that any tool which can transform a source tree should also support
an
>object model to query the source tree.That is the reason why I was
thinking
>of XSL rule patterns and DOM interfaces together in XSL at the same level.

Before I say anything else, I should point out that I'm just an opinionated
novice as far as XSL goes... <smile> But I've been pounding on an
implementation of the Document Object Model all year, which biases me
toward modular design rather than explicitly entangling the two standards.

I _think_ the answer is that if a particular tool wants to support both XSL
and the DOM API, it's free to do so... but that doesn't mean XSL itself has
to be made DOM-specific. An XSL engine might read a document from a DOM and
creates a new DOM tree as its output, but that's just one possible
implementation.

In your example, you want to retrieve the element name, in much the same
way that {attribute(foo)} retrieves the value of an attribute. That's an
interesting question; I don't see a way to do that in the current spec, but
I think I agree that it probably should exist ... for debugging value, even
if nobody can come up with a realworld example that needs it.

As I read the proposal, XSL's object model, if any, is hidden under the XSL
syntax; there's no way to get at it directly. There has been discussion of
adding a scripting capability to XSL, to allow user-written functions to
extend XSL's capabilities; in order for that to work some such model would
be required, and speaking only for myself I'd like to see it be based on
the DOM. But it sounds like this is still in the "to be examined" category,
might not be present in all XSL systems, might be application-dependent...
and really shouldn't be required for straightforward transformations such
as your "list all element names" example.
______________________________________
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