xml-dev - Re: XSL Debate, Leventhal responds to Stephen Deach

[Paul Prescod <paul@prescod.net>]

"Simon St.Laurent" wrote:
> 
> CSS+XML doesn't allow them to post semantic markup?  (CSS by itself doesn't
> let you post _anything_, so I don't know what you're talking about.  HTML?)

When you sit down to implement an XML system the last thing you think
about is CSS, XSL, or the DOM. The first thing you think about is the
needs of the data. If you have any volume of textual data, you will
probably not get another opportunity to re-encode all of it until CSS and
XSL are historical artifacts, Microsoft is a division of Red Hat, and the
Web has more users than the telephone. 

So you *must* concentrate on the needs of the data. You must make richly
semantic markup that captures the structure of the data. And you must have
human authors start to add this semantic markup to the data as soon as
possible. You must minimize the cost of this markup effort.

Having done this process right, for a sophisticated document type, it is
highly unlikely that you will be able to display your documents directly
using CSS. Graphics will cause a problem. Cross references will cause a
severe problem. Navigational mechanisms will be lacking...and so forth.

Therefore you cannot just stick the XML file and a CSS stylesheet on your
website. You must dumb down the XML somehow -- to HTML or to some weakly
semantic variant that has redundant cross reference text, redundant
navigational mechanisms, HTML-compatible IMG tags and so forth.

Without some client-side transformational mechanism (either XSL or the
DOM), CSS *discourages* the distribution of rich semantic information
because it requires you to dumb down your data.

> The question is not whether FO's harmfulness is solvable, it's whether it's
> an acceptable cost.  I see it as a cost that wouldn't have been incurred
> had we stuck to annotation for formatting - while you could strip semantics
> to SPAN and DIV if you really wanted, the whole selector mechanism of
> Cascading Style Sheets discourages such practice.  It would have taken an
> extra level of processing to do that stripping.

As I described above, CSS requires the "extra level of processing" anyhow.
The difference is that XSL and the DOM allow that extra level of
processing to be *client side*, which means that the client is working
with rich data. Without transformation languages, CSS requires the dumbing
down to be *server side*. This isn't an argument against CSS. It's an
argument FOR transformation languages (used, sometimes, in concert with
CSS).

> In this case, 20/20 hindsight for the XSL community is an "I told you so"
> for the CSS community.  Take a look at the early battles on XSL-list and
> you'll see that I'm saying nothing original here - these arguments were on
> the list before I even subscribed.  Doesn't it seem like our responsibility
> to learn from the lessons of _one_ year ago rather than racking up the same
> kinds of problems again and again?

A year ago the XSL specification was explicit in its goal of achieving
compatibility with CSS. It referred explicitly and directly to CSS
properties. There was a separate working group formed to develop a
cross-language formatting model. As far as I can see, the FO model and the
CSS model are very close. I certainly hope so: I will soon be teaching FOs
by teaching CSS first!

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

[Woody Allen on Hollywood in "Annie Hall"]
Annie: "It's so clean down here."
Woody: "That's because they don't throw their garbage away. They make 
        it into television shows."



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)