Fw: W3C-transformation language petition

Subject: Fw: W3C-transformation language petition
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Thu, 4 Mar 1999 22:56:18 +0200
Ian Hickson <py8ieh@xxxxxxxxxx> wrote:
>This is my first post here. I've been lurking for some time, and I
>feel there are some misunderstandings within the XSL community as to
>what CSS can do and especially how its syntax works.


We are all here to learn :-)


>...
>
>What about an aural rendition?
>
>Will XSL be able to cope with alternative (non graphic) media? CSS
>can. This is quite an important issue.


Good question. I'd say CSS is better suited to handle alternative media the
FOs are. FOs are designed around a 2D graphic layout paradigm. In CSS, one
could add new "display" types and their related attributes.

>> The only problem is that CSS does not provide the full set of
>> attributes necessary.
>
>Quite seriously, what is it that in the opinion of FO proponents is
>missing from CSS? (Other than tree transformation, obviously.)


Well, FOs handle pages better, handle international languages better, and so
on. Nothing CSS couldn't in theory do, it is just that the relevant
attributes and air-tight semantics haven't reached the standards yet - not
to mention the implementation. I imagine the print people would have a lot
to say about this issue :-)

>And now the *really* off-topic part:
>
>> And, of course, the syntax of CSS should be replaced by an XML
>> compliant one :-)
>
>I know that some people feel this quite strongly.


Guilty :-)

>The reasons I have seen put forward basically boil down to "You don't
>need Yet Another Parser".

That's almost it, but not quite. The problem is that the DOM <=> XML mapping
is no longer simple. It becomes different for CSS data. The DOM API would no
longer be sufficient, by itself, to be able to generate a correct XML tree
for the document, and the SAX events for parsing the XML document would no
longer be sufficient for building the in-memory DOM. I find this very
disturbing.

Oh, one could work around this - demand that every XML parser/emitter would
know to switch formats in mid-stream to handle CSS. Think of the
consequences if each time an extension was made to vanilla XML 1.0, a new
syntax was introduced - a new one for name spaces and a new one for schemas
and a new one for transformation (yes, one could argue XSL could have a much
easier syntax if it wasn't XML) - what would be left of XML, then?

>...
>
>Besides the problem of the "rule" element having a gazillion
>attributes in the DTD, and the fact that shorthand properties *cannot*
>be dropped (they do a lot more than just stand in for other
>properties: they also reset related properties in one go), there is
>the parsing problem.
>
>Anybody who honestly believes that the above only requires an XML
>parser to parse is strongly mistaken. For example:
>
>    <css:import url="..." media="projection tv">
>
>The media attribute needs parsing into space separated keywords.


There's nothing wrong with an attribute having complex internal semantics.
My application has quite a few. The important part, however, is that it is
accessed as a single DOM attribute. Once you start providing access to each
sub-part as a separate attribute, with its own name, we start having
problems. There's nothing wrong with "media" having a value which is a list
of words.

>    <css:rule pattern="P:first-child + P EM"
>
>The pattern attribute needs some serious parsing, which cannot
>(AFAICT) be spelled out in XML easily (and certainly not as tersely).


Actually this could be more XML-ish if it was specified as the equivalent
XSL match pattern. Another reason I think XSL is the right place to discuss
this issue. For one thing, the match pattern would have to be enhanced by
several CSS "pseudo classes". Other then that, as terse as the CSS patterns,
and definitely more powrful.

>Furthermore, XML does not define how errors should be dealt with,
>which is a rather big constraint on future-proofing. CSS has extremely
>specific rules for error handling.


This is a difference in philosophy. XML is big on validation, CSS on going
on and doing something regradless of errors. Each has its merits. In the
particular case of mal-formed documents arriving over the net into a
browser, I think it can be safely assumed that browsers will do their best
to handle it, regardless of which syntax is used. "Go on processing" is a
perfectly valid "undefined behavior".

>There is also a semantic reason why CSS should not be written in an
>XML syntax: XML documents represent trees. CSS does *not* have a tree
>structure. It has a structure well designed to _decorate_ such trees.


You could say that XSL doesn't have a tree structure; it has a structure
designed to _transform_ tree. And so on. The fact is, that almost anything
in computer science maps very naturally to trees. This is what makes XML so
sucessful. Problems start when you try to handle general graphs. CSS maps
very naturally to a tree structure, as deonstrated by the ease of
integrating it into the DOM.

>Another problem with the concept of using XSL to style documents is that
>XSL is not, AFAICT, dynamic (unless you go in with the DOM and directly
>change the tree structure, which is quite a drastic thing to do, and
>certainly isn't quick and easy). Once the tree has been transformed into a
>set of FO elements, you are stuck with that tree, and in particular you
>are stuck with that style. With CSS, you can easily change the styles
>merely by using the DOM (level 2, currently in draft stage just like XSL
>itself).


Yes, this a clear advantage of CSS over (FO-based) XSL. This is the major
reason FOs will never make it inside browsers. IMVHO, of course.

>Personally, I think I will be using XSL mainly to transform the
>document so that it contains a structure suitable for formatting.


No arguments from me. Now try to convince the XSL WG :-)

Share & Enjoy,

    Oren Ben-Kiki


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


Current Thread