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

David Carlisle <davidc@xxxxxxxxx> wrote:
>... The only question is whether to split off the formatting objects into a
>separate language.
>
>Given that you have a transformation language, there is nothing to stop
>you have a target XML DTD that abstractly describes a formatted document
>and then you can transform to that.


Exactly.

>That I gather is what texml is (I plan to get it this week and look)
>and of course you could write any other formatting language in XML
>syntax followed by a simple translation to its native syntax.


Right.

>I see two problems with this approach.
>
>Firstly by targetting a specific language you lose (or at least have to
>work harder to regain) the cross system abilities of a system like dsssl
>or xsl. I can write far more expressive and powerful formatting
>requirements in tex than I can in dsssl; but if I do it in dsssl then I
>can produce the same document, with essentially the same style, produced
>from the same style sheet, in TeX or rtf for MSWord etc, or mif for
>framemaker.


True, it would be nice to have a "universal" formatting language - HTML as
it stands today isn't adequate for several reasons. Just as it would be nice
to have a universal programming language and a universal spoken language,
and just as unlikely to ever happen :-) We can have a fairly portable one,
though.

Anyway, I fail to see the relevance. Why does this need depend on having
transformation abilities within the language? You imply that if we split the
transformation part out, then the universal formatting language would wither
away and die. I don't think this is the case. And if it is, is it fair to
saddle the transformation language with a non-viable different need?

>The second thing you lose by separating the two is adequate feedback
>between the style language and the transformation. Currently this is
>not there in XSL (and is weak in DSSSL implementatons like jade that have
>a clear break between the front end dsssl engine and the back end
>typesetter). However if the languages are separated there would be no
>chance of ever improving this. The main reason why TeX is more
>expressive as a style language is that the transformations can be
>controlled by the results (or potential results) of the typesetting.
>That is, you can say `if this caption would fit in the margin in under
>three lines, do that' else do something else (which may involve
>completely re-arranging the page makeup, so that it does all fit).
>If you have a model where the transformation is done first, and then you
>just run the result through a simple style language then you are never
>going to be able to express complicated page makup requirements. As you
>can not answer questions like the above without having direct access
>to the formatter.


Sorry, I don't see TeX as a transformation language. Merely being able to
place an "if" in a language does not make it transformational. I think
transforming XML into TeX is a very good example of how transformations and
formatting can be separated. In fact, in this approach, the generated TeX
would be simpler then the one needed today - issues such as collecting the
table of content would be unnecessary.

>> Of course, non-trivial formatting tasks will require that you use both,
but
>> they're still designed better in (relative) isolation.
>
>But the problem is that you need to use both interleaved at multiple
>points in each visual area. You can't do all the transformation then
>all the formatting in two simple steps.


Can too :-) Take for example the TexInfo system. It takes TexInfo files, and
transforms them into either TeX for printing or into Info for interactive
browsing. I used it on several occasions with great success (BTW, did anyone
ever write an HTML output for it?). No feedback from either TeX or Info was
necessary, simply because these languages are expressive enough for their
respective jobs. What we need is a good transformational language and a good
formatting one - and then we wouldn't have a feedback problem.

Share & Enjoy,
    Oren Ben-Kiki.


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