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

Subject: Re: why split? [was RE: XSL intent survey]
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Mon, 23 Nov 1998 19:46:05 +0200
David Carlisle <davidc@xxxxxxxxx> Wrote:

>so basically we agree, it's just a case of how to manage the details...

God (and the Devil) are in the details :-)

>> And if it is, is it fair to
>> saddle the transformation language with a non-viable different need?
>If it was really saddle as in `place an extra burden on' then I would
>agree but I don't really see this is the case. What I'd hope to happen
>is that _some_ XSL processors go all the way and produce some formatted
>output, others might work as xt does now which is to do the transforms
>but if you transform to formatting object it outputs the XML tree
>representing same, rather than actually rendering anything.

Try it the other way - is it fair to saddle a formatting language with an
unrelated need, that of being a complete transformation language? Let us
recall that this whole thread started since requests for certain
transformation features were rejected (well, at least discouraged) on the
grounds that XSL is intended to be a stylesheet language and not a complete
transformation language. If XSL was intended to be both we wouldn't be
having this problem. Personally I think that is too much to stuff into a
single language.

>> Take for example the TexInfo system. It takes TexInfo files, and
>> transforms them into either TeX for printing or into Info for interactive
>> browsing.
>But the structure of the two is essentially the same.

Well... There are structural transformations involved. Whether they are
"essential" is something very slippery to define. At any rate, an example of
a system which doesn't require feedback doesn't prove feedback isn't
sometimes necessary; I just wanted to give a sample of how far you can go
without such feedback - very far providing the target language is strong

>My point is that
>in a combined language you can for example re-order elements based on
>their typeset size, so if you get a whole load of figures or footnotes
>or whatever and they turn out to be small then you may choose to typeset
>them inline in some way rather than displaying each one full width.
>If you make a decision like that then you are writing a completely
>different formating object tree. However the _input_ to the decision
>process is the size of _trial_ typesetting of the constituent elements.

I have no problem with a formatting language containing high-level
instructions to the formatting engine. Formatting tags which include
alternatives for various conditions (e.g. sufficient place on the page), or
giving the engine leeway in positioning elements (e.g. floating figures) are
good examples. Some things would admittedly be impossible - say, ordering a
list based on the width of the text in each entry. I'd like to see a
concrete example of a _useful_ transformation which would become impossible.

I suspect that such features are not in demand. To justify this feeling I
can say that I haven't seen requests to extend XSL in this direction. On the
other hand, I've seen several pleas to keep XSL simple, when requests to add
complex transformation features were submitted.

>... it is possible to imagine that certain
>set of such decision processes could be codified into an XSL construct
>of some form that did give a representation which allowed querying the
>result of the formatting in a way that allowed the transformation
>to reject certain possibilities and transform to a `good' typeset

I agree, except I'd use "format" instead of "transform". But that's exactly
the issue, isn't it :-)

>So to some up I would say that if the two were split then:
>those needing just the transformational part would be in the same
>position, with the exception that the systems they are using would
>describe themselves as being XTL rather than `transformation-XSL'.

And they would be able to add modes, and scripting, and local variables, and
whatever, without having the formatting people complain that "it is too
complex" and "this isn't in the intent". It also would become possible to
have a standard XTL processor without having to add "without the formatting
semantics" (standard conformance is important!).

>Those only needing direct formatting with no transformation at all
>would probably use CSS-n.

They already do :-) If XFL would be simple they'd have the incentive to
switch to it and if it were easy to implement (as in no complex
transformations), browsers would correctly implement it giving them the
opportunity to do so.

>Those needing `moderately complicated' stylesheets would have to
>split the work between a transformation phase by a transfromation
>language producing something to be reparsed and formatted by a separate
>formatting language.

Allowing them do cleanly separate concens (why does collecting the table of
contents, or reordering products by price, have to be intermixed with
choices on which font to use?). I could also make the claim that separation
of computation locations also makes sense here - if all you want to see is
the TOC, it doesn't make sense to send you whole book over the internet and
then have your XSL extract it on the client, does it?

>Those needing `complicated' style sheets would be stuck. Unless someone
>implemented a language with a possibility of tight coupling between
>formatting and transformation.

As I said I'd like to see some real-world examples of things you can't do
with separate transformation and formatting passes - given that the
formatting language allows you to respond to formatting queries in a
reasonable manner.

>If this last language could in fact be
>used as the transformation language by the first two groups of people
>then there would be no need for having all these separate languages.
>(This might be a big if, but if this fails and you are _forced_ to split
>then so be it, but don't _aim_ to split as an ideal outcome).

This "if" depends on how complex you allow XSL to become. I think that the
KISS approach to the formatting language is important. A language doing both
general transformations _and_ formatting would be anything but simple.

>I can't see the gain in the split for any of the above groups,
>but probably it is a biased categorisation...)

Well, I think I pointed out advantages to the first three, which I feel
cover most of the users/applications/needs. As for the last group all I can
say that in general it isn't worth bending systems out of shape to satisfy
the extreme cases. This is also probably a biased opinion - though I've been
working on "extreme cases" several times myself :-)

Share & Enjoy,

    Oren Ben-Kiki

 XSL-List info and archive:

Current Thread