[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]