Re: Venting

What a great thread.

I've got one observation (speaking obviously as a potential user of XSL, or
whatever it turns out to be, rather than an actual implementor), and one
"middle way" proposal.

Observation: A couple of months ago, in clearing up one of the (then)
confusions about XSL, James pointed out that XSL's style mechanism is
intended to operate on the result tree, rather than the source tree, coming
out of XSL's transformation mechanism. That seemed clean to me. Still, I
wonder if what's being discussed now isn't a recasting of that original
question: Cleaving the two would enable the style component to process
*any* well-formed tree, no? Wouldn't that enhance the appeal of the style
component?

Proposal: Someone else on this thread has mentioned the importance of
calling things by their right names. This gets at what is meant by "style"
-- the "S" in XSL. That used to trip me up all the time, until it became
clear (sometime last summer) that the word "style," despite its common
everyday use, really means *behavior*: transformation+formatting. So: Would
it help resolve the conflicting issues of both the "Split it!" proponents
and the "Don't delay it!" proponents (and incidentally, those bound to
abide by the WG's charter) to simply call Section 2 "XSL-T" and Section 3
"XSL-F"?

I know you're all in this much more deeply than I am, and that I'm probably
overlooking enormous subtleties (if that's not a contradiction in terms).
Just thought I'd throw it in and return to the bleachers.

Best,
JES

====================
John E. Simpson
Just XML (ISBN 0-13-943417-8)
Available now from Prentice Hall PTR


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