OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [docbook] Whatever happened too CSS+XML?


Apologies for not keeping the thread; I'm posting through a web interface to my company mail account.

>> -----Original Message-----
>> From: Noah Slater [mailto:nslater@gmail.com] 
>> Sent: Tuesday, November 08, 2005 7:55 AM
>> To: Paul Prescod
>> Cc: Steven T. Hatton; docbook@lists.oasis-open.org
>> Subject: Re: [docbook] Whatever happened too CSS+XML?
>> 
>> I think perhaps you are missing the point. I don't think 
>> anyone here is saying that CSS is the equivalent of XSLT, or 
>> in fact, anything similar.
>> 
>> I think the major point is that if you want the semantic 
>> goodness of an advanced XML document type such as DocBook 
>> without any of the post processing goodness of XSLT - CSS is 
>> more than an adequate way of styling this information for the user.
>
>
>"If you don't need XSLT's features, don't use XSLT." Fine.
>
>But what Steven said was:
>
>> Using XSLT to transform XML into Netscape 4.7-compatible tag soup HTML
>
>> is -- at best -- a wasted effort.
>
>Perhaps what he should have said is that it CAN be a wasted effort in
>SOME cases. Which is also close to a truism. 
>
>So I see the whole "debate" (which has been running for around 7 years
>now) as a waste of time.
>
> Paul Prescod

I'd like to take the blame for stating that using XSLT to transform XML into Netscape 4.7-compatible tag soup HTML is -- at best -- a wasted effort.

That was in response to Dave Pawson's statement:

>Rubbish.
>When CSS gets implemented
>When CSS is accepted
>It still won't have 10% of the capability of XSLT.

I'm in the legal publishing business, which means customers want indices and cross references; it is a large part of the value that we add to laws, regulations and court cases. We make good use of a number of SGML and XML technologies, including XSLT.

So I'm not opposed to using XSLT, it's appropriate for a lot of what we do. But XSLT and XSL-FO are not universal panacea, and I'm not going to use XSLT (or any other technology) just because it is 'cool', and I won't avoid it just because it is 'uncool'. E.g., for the yearly four-volume 5000 page tome on tax law, using FrameMaker for page composition provides us more bang-for-the buck than XSL-FO can -- right now.

I recognize the sentiment in this lament from Rick Jeliffe [1]:

"I don't want to shock my gentle readers, but biggest sign of how far XML has emerged from its publishing roots is that the index refers to section numbers not page numbers: probably unthinkable for an SGML book!"

So what am I opposed to? I'm opposed to premature optimization and needless complexity. 

Todays commonplace user agents are about as capable as SGML IETM browsers were a decade ago. They do render a significant part of DocBook directly. But for a variety of reasons, you might not want to serve your storage format directly to the user agent: you'll want to filter out some content and metadata, and you will want to add some content and metadata. When you publish (more than a few stand-alone documents), you'll need a publishing pipeline. You'll want to 'normalize' and mix content from a variety of XML vocabularies, and you'll want to re-purpose for different media. Some architectural form of XHTML is inevitably involved as an exchange format.

Earlier this year, it was suggested on the docbook-apps list that lean clean XHTML output might be desirable for some purposes [2]. As Bob Stayton says [3]:

"Since this XHTML would be dependent on CSS for styling, I think the spec would have to include a template for the CSS."

This "template for the CSS" would amount to a declarative spec for rendering expectations of (a significant part of) DocBook elements. The CSS should be modular to better refelect the various genii and species of DocBook elements. A modular template might rely on extensions similar to XXE's [4], or a trivial representation of the CSS syntax in XML.

Every 3 years or so, someone asks 'Why isn't CSS expressed in XML? Why don't CSS use XPath-based selectors?' It's a sorry state of affairs [5]. It should have been S-expressions, all of it :)


Kind regards
Peter Ring


[1] http://www.oreillynet.com/pub/wlg/8306
[2] http://lists.oasis-open.org/archives/docbook-apps/200504/threads.html#00228
[3] http://lists.oasis-open.org/archives/docbook-apps/200504/msg00230.html
[4] http://www.xmlmind.com/xmleditor/_distrib/doc/csssupport/prop-group-value.html
[5] http://www.biglist.com/lists/xsl-list/archives/199906/threads.html#00202


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]