[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: Re: why split? [was RE: XSL intent survey]
From: David Carlisle <davidc@xxxxxxxxx>
Date: Mon, 23 Nov 1998 14:19:13 GMT
examples split latex document
> Exactly.
> Right.
> True,

so basically we agree, it's just a case of how to manage 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.

> 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.

Of course, it is what you put in the `if' that makes all the
difference:-)

> 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. 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.

This is the way you work in TeX all the time. It's not the way you code
most tex documents, but someone (perhaps me) codes up these kinds of
decisions which are then used in the formats like latex that typeset
document instances.

XSL being essentially _not_ a programming language is never going to
work quite that way, however 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
layout. 

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'.

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

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.

Those needing `complicated' style sheets would be stuck. Unless someone
implemented a language with a possibility of tight coupling between
formatting and transformation. 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).

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

David


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.