[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The XSL-List Digest V1 #192

Subject: Re: The XSL-List Digest V1 #192
From: keshlam@xxxxxxxxxx
Date: Tue, 27 Oct 1998 14:50:24 -0500
Re: The XSL-List Digest V1 #192
>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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.