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

Fw: Fw: W3C-transformation language petition

Subject: Fw: Fw: W3C-transformation language petition
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Wed, 3 Mar 1999 12:48:30 +0200
w3c css2 expression
Guy_Murphy@xxxxxxxxxx wrote:

>So moving on from that, we come to should we persue FOs, or simply move
>forward with CSS?
>
>It's only a matter of my own opinion, but I think that XSL FOs cast adrift
>by themselves will ensure that we never get to find out :)


To put it blatantly, either:

- FOs satisfy a real application need and have advantages over CSS. For
example, as being "the" XML way to describe printed documents - an XML
alternative to PDF, RTF, and TeX. If this is so, why wouldn't they catch on
by themselves, without being linked to XTL?

- FOs have no advantage in real world applications over CSS. By linking them
to XTL there's a chance of forcing people to use them, otherwise they'll
just wither away. Doesn't sound like a good reason to me. Of course, one
might soften the above by saying that _today_ FOs have no advantage over
CSS, but in the long run the FO approach would prove to be better. I'd say
that comparing future FOs to future CSS is risky at best. So far, I know of
things CSS can do and FOs can't, not the other way around.

Even you admit that:

>XML + CSS allows us relatively rich expression of formatting, and if CSS is
>extended, this could become extremely rich.

So I don't put much weight to the "long term benefits" excuse.

>This does two things however,
>it encumbers lower-end authors that might have regarded CSS as a
>lightweight alternative to XSL FOs with an equally heavy CSS spec.

I feel a single way to do something, where a subset of the features is
commonly used and some are kept for special occasions is better then two
radically different approaches, one tauted as "simple" and one as "complex".
Especially since the "simple" one is actively being made more complex as we
speak (CSS2).

>The second things we loose when we loose XSL FOs are the basic semantics of
>formatting. Unlike CSS, XSL gives us not just the formatting properties,
>but the basic formatting objects.

Here we have a basic disagreement. I don't see how "display: block" is any
different then <fo:block>. Both should/could have exactly the same
semantics. What FO calls "formatting objects" CSS calls "possible ways to
display things" and instead of making it the element type, it is put in an
attribute. Why is one "basic semantics" and the other "just a property"?
Consider the purely syntactical transformation

<MyElement style="display: block; background-color: red">

Into:

<css:block element-type="MyElement" background-color="red">

Does this make it "basic semantics" again?

>We are left then either with a
>free-for-all, with no common conveyance of intent, or the pinning of CSS on
>existing XML applications that may or maynot bear any relationship
>semantically with generic formatting.


The CSS approach isn't "free for all". Element structure follow presentation
_exactly_ like the element structure used by FOs. The fact that CSS
attributes are stuffed in a single "style" attribute is unfortunate, and
could be easily fixed. Other then that, FOs and CSS are essentially the
same - except that CSS defines style sheets which go beyond what FOs have to
offer.

>One interesting issue raised in the current draft is... "XSL should support
>interaction with structured information, as well as presentation of it. ".


Does that mean XTL? :-)

>Now as yet there has been little examination of the role XSL has (or maybe
>hasn't) to play alongside XLink. I believe that presentation of navigable
>relationships is something that should involve XSL, and that it involves
>both transformation and formatting. I'm not sure if it's fair, or
>beneficial to drag CSS off down that avenue.


If one keeps transformation and formatting as separate issues, then there's
no "dragging". Embedding documents via links etc. is clearly a
transformational issue. Once done you use CSS to style the result. Anything
wrong with that?

>And then there are issues such as transclusion or simple data aggregation.
>We can look at ways of expressing such things with FOs, but such expression
>without recourse to basic building blocks becomes increasingly difficult in
>CSS.


Again, anything that can be done the FO way can be done the CSS way.
_Anything_ (counter example, please?). I'm not certain this particular issue
should be handled at the FO/CSS level, though.

>I think both these issues warrant a close look as they relate to XML
>styling or indeed document construction. If we are simply rendering a
>document for print, this isn't much of an issue beyond a desire for rich
>visual formatting. If however we are presenting a navigable document in a
>user agent then we are in the business of document construction and must be
>able to address link relationships within that construction. I don't think
>CSS is about to do that for us, and I'm really not sure it should be asked
>to.


Neither should FOs :-) Navigation means interactivity, and interactivity
means programming, which means it is outside the scope of both. Describing
transformations declaratively is barely possible, as XSL has deonstrated.
Doing the same for interactions is flatly impossible - barring some
breakthrough worthy of a Turing award. Let's keep separate issues separate.

>I said before that all CSS really was was a formatting language. I'll risk
>my arm and go a step further saying that all CSS is really is a set of
>farmatting parameters :)


I refuse to bite :-)

>Again I'm not knocking CSS. Given a certain set of design considerations
>I'd be a strong advocate of CSS, and my hope is that both CSS and XSL
>flourish in the market-place. It's just I don't see CSS as likely to become
>the complete XML styling solution.


First, XSL could have been a great opportunity to add these design
considerations into CSS. That's exactly the point. Second, _nothing_ is
going to be the complete XML styling solution. I'll risk any part of my
anatomy to bet that people will still be using TeX ten years from now, and
therefore there will be TeXml users.

>In terms of Web design, XML introduces a new paradigm in document
>construction, and it's important that we have the tools in the form of rich
>languages to describe XML document construction, and more importantly that
>are designed to work as part of a cohesive whole.


The goal is clear; the right way to achieve it, much less so :-)

>By designing XSL FOs from the ground up we can ensure that they fit in well
>with other XML related languages.


I find this a surprising statement. First, why does a purely formatting
language have to "fit" with any other? If you had said that about CSS, I'd
understand, since CSS is used to annotate documents in arbitrary languages.
Sounds like a better "fit" to me :-)

>The XSL FOs are probably the throniest part of the whole XML pantheon as
>they require considerable effort on the part of the browser manufacturers
>to impliment. Given past experience with the two companies on which most of
>the WWW rely to view content, namely Microsoft and Netscape, it would
>appear that their path has been the one of least resistence. It is for this
>reason that I fear that if we give them an oppertunity to remove the thorn
>of rendered XSL FOs from the side of XML, we are likely to be looking at
>CSS formatting parameters for a very long time.


First, I think that these companies are large enough to ignore this thorn
regardless of any official standards. Unless FOs fulfill a real need better
then CSS does, they will never catch on. Period. Second, assuming that this
is the case, why not make the best of it? Let's use XSL as an apportunity to
rectify the obvious flaws of CSS - the non XML syntax, for example.

If you can't beat them, join them :-)

    Oren Ben-Kiki


 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.