Re: why split? [was RE: XSL intent survey]

Subject: Re: why split? [was RE: XSL intent survey]
From: Guy_Murphy@xxxxxxxxxx
Date: Mon, 23 Nov 1998 16:22:05 +0000

On the subject of a super or subset approach to XSL, wouldn't it be the
case of transformation as the core
and formatting as the superset?

XSL at essence is surely transforming one XML tree into another... am I
missing something here? If it's not transforming
you feed XML in, and all you get out is... what, the same XML?

And while it may not be the case in fact, I had certianly fallen into
thinking of the XSL flow-objects as a superset of XSL core... although I
on reflection that this may well be an erroneous attitude on my part (I'll
have to go to the spec and think on that.) I think this position
understandable as the flow-objects occupy a seperate namespace.

I'm going to have to go back over the archives really and read up on the
history of this discussion of an XSL split... I'm obviously
missing something fundamental.... and I shouldn't really be shooting my
mouth off from an historicaly ill-informed position.

It just seems to me we have XSL transformation syntax, which can be refined
and developed, and on top of that we have proposed flow
objects that may be *optionaly* used (sounds like a superset to me). I'm
not understanding what the problem is with this arrangement.

As for the issue of XSL operating like a scripting language... Why?

Why would anybody want it to. If you want XML transformation with a
programatic approach rather than a declarative, descriptive approach
there are countless languages one could choose to do this with. For those
that want to push the extra mile, <xsl:eval> with ECMAscript
would do that (if it becomes part of the spec.)

So we'd have transformative declarative syntax, with optional flow objects,
and optional scripting. To my mind (and I realise
everybody has their own biased interests) this would be an appropriate
order for prioritising consideration.

Please feel free to knock holes in my statements, I'm genuinely assuming
that I'm missing something here, and would appreciate being filled in.


xsl-list@xxxxxxxxxxxxxxxx on 11/23/98 04:51:51 PM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  Re: why split? [was RE: XSL intent survey]

Oren (et al.) --
Something just occurred to me that might let us "have it both ways." I
offer it in the hopes that it will either be peppered with buckshot as
essentially unworkable, or not :).
The discussion has been framed as a choice between splitting XSL into
transformation and presentation components, and putting both of those
components into a single baseket, as it were. I wonder if there might be a
"middle way": supersetting XSL with a more robust transformation-only
level. As I'm envisioning it, XSL-Core would provide all of the formatting
facilities and a modicum of transformations -- certainly at least those
necessary to make the formatting work. XSL-Enhanced (or whatever) would use
the same "syntax" as -Core but provide a richer, more complex set of
transformational capabilities (such as those possible with full-blown DSSSL
or TeX, maybe, although I'm not familiar enough with either to say for
This would not completely resolve the issue. As an XML application in its
own right, XSL would still remain at root a declarative language, not a
procedural one, and so those who long to make it function as a "scripting"
language are probably going to remain disappointed.
John E. Simpson          | It's no disgrace t'be poor,
simpson@xxxxxxxxxxx      | but it might as well be.
                         |            -- "Kin" Hubbard

 XSL-List info and archive:

 XSL-List info and archive:

Current Thread