Re: XSL Requirements (was: Microsoft extensions to XSL)

Subject: Re: XSL Requirements (was: Microsoft extensions to XSL)
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Mon, 16 Nov 1998 12:34:22 +0200
Ed Nixon <ed.nixon@xxxxxxxxxxxxxxxxx> wrote:
>[Obk] ... I think we have a basic disagreement between people who use
>the first part of the intent - XSL as a transformational language - and
>people who also care about the other part, the formatting semantics.
>[edN]  I wonder how much of this split will still exist in 6 + months when
>browser bowsers manage to get something working with respect to XML and
>XSL, and even DSL? (I've mentioned the InDelv alpha/beta code before as and
>example of alternatives -- pretty good support for basic formatting objects
>la current draft, not so strong but still respectable on the

My bet is that the formatting part of XSL would just wither away. CSS seems,
at the moment, to have much more momentum as being "the" style sheet
language. On the other hand, XSL seems to have a fair momentum as being
"the" transformation language to use... Of course, my crystal ball doesn't
have a warranty :-)

>[Obk] The first group would like a transformational language which is
>enough to convert XML into whatever target language they need. Being
>accessible to the end user is a minor concern.
>[edN]  We've just seen some  posts pointing to all sorts of alternatives
>doing this. If the argument is that it should be done client side as
opposed to
>server side, I wonder if this is realistic at this point in the evolution

It is. There are great benefits in doing this - reducing bandwith,
increasing application responsiveness, reducing server loads... And clients
today are Pentium II machines with cycles to spare. It makes perfect sense
to go this way. In fact, my company was going to do client-side
transformations regardless of XSL; we chose XSL over rolling our own
transformation engine so as to better integrate in the evolving Internet

>[Obk] The second group would like a flexible style sheet language for HTML
>designers. Being accessible to such designers is a major concern.
>[edN]  I wonder how much of this pent-up and frustrated demand can be
placed at
>the doorstep of the rather half-hearted, inconsistent and downright buggy
>implementations of CSS that we have to contend with?

Exactly. But I expect that the next generation CSS implementation would be
much better, by then people would be used to CSS, and the XSL alternative
would be less relevant.

>[Obk] Is there any chance of splitting the XSL draft into two - say, XTL
>(eXtendible Transformational Language) and XFL (eXtendible Formatting
>[edN]  In effect, this has been done (if not formally announced), I think.
>There was some back and forth a month or so ago about focusing on the
>transformation side in the short term (whatever that means) and leaving the
>formatting side to later in the process. Realistically, what tools exist do
>this and not much of anything else -- XP/XT, Koala XSL
>I wonder if the division isn't rather neatly captured already? On the one
>in the notion of the template matching and relatively straight forward
>mechanism, i.e., new tag names, additional text, process-children, etc.; on
>other, with the 'fo' mechanism, i.e., display space management, graphics,
>formatting, etc.
>Are you suggesting that there should be two separate and free standing

Yes, exactly. I think the formatting semantics should be just another XML
language. It could compete with CSS on an equal basis for being the
stylesheet language of choice. This should not effect the use of XSL as a
transformational language.

>Maybe I'm already corrupted but I like the notion of being able to select,
>change/re-order, and show content all in the same place.

Selecting and re-ordering are transformational processes. As for showing the
content, by generating XML <fo:*> formatting tags - I'd like to see a design
criteria which defines what is the scope of the <fo:*> name space. In
particular, given some issue regarding display of some entities, should it
be in <fo:*> or does it warrant a separate XML language? Keep in mind we
have quite a few display related XML languages in the works - for 2D/3D
graphics; for mathematical formulas; not to mention we have the HTML
"display" language.

>What I'm not so convinced is necessary is the ability to run a bunch of
>procedural code as well -- this was the thrust of my initial response to

As Didier PH Martin (mailto:martind@xxxxxxxxxxxxx) correctly pointed out, a
pattern matching language is never sufficient by itself to do general
structural transformations. He's also correct in that it would have been
interesting to start with a procedural language (say, JavaScript) and add
pattern matching facilities to it, instead of starting with a pattern
matching language and adding procedural hooks to it.

The benefits of XSL's approach is that the simple things are less
intimidating then they would have been in a souped-up JavaScript approach.
This may explain the level of interest that XSL has generated. But to keep
and build on this level of initial interest, XSL must provide the ability to
do the more complex stuff as well. There are several features which related
to this, not only scripting language integration - processing modes is a
good example, and local constants/parameters, and so on.

Share & Enjoy,

    Oren Ben-Kiki

 XSL-List info and archive:

Current Thread