[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook] DocBook on the Web
Elliotte Harold <elharo@metalab.unc.edu>, 2006-11-01 05:51 -0500: > Reading Norm's latest post > <http://norman.walsh.name/2006/10/30/openMind> I wondered, has anyone > tried publishing straight DocBook on the Web? i.e. sending real DocBook > XML + (CSS | XSLT) to the client; not doing the conversion server side > or earlier and sending HTML to the client? If so, what were your > experiences. > > My suspicion is that even assuming client side support there are several > problems: > > 1. There are no straight CSS stylesheets for DocBook. There are actually some CSS stylesheets that David Holroyd developed and contributed to the DocBook Project (and is continuing to maintain): https://svn.sourceforge.net/svnroot/docbook/trunk/css/xml/docbook/ He has some examples a test cases at his own site: http://www.badgers-in-foil.co.uk/projects/docbook-css/ Those even include a localization mechanism for generated text: http://www.badgers-in-foil.co.uk/projects/docbook-css/tests/localisation-gen.xml > 2. The XSLT stylesheets are too complex to reasonably render client > side. I think there are bugs and limitations in the browser-based XSLT engines that prevent them from being able to load the stylesheets. That said, most command-line XSLT engines other than Saxon and xsltproc also seem to have problems with the DocBook stylesheets. > They also likely rely on extension functions browser engines > don't have. I think node-set() is the only extension function that's required in any part of the DocBook XSL stylesheets for HTML output, and the only features that require it without a fallback are optional features (namespace stripping, fast chunking, internationalized indexing). (And MSXML and Opera's XSLT engine actually both support node-set()). > 3. Anything beyond an article is too large for one page, and it's not > really possible to chunk pages on the client side. I think it would be possible to load an entire document into the browser and use a Javascript mechanism to chunk it into logical pages (along with all the on-page previous/next/ home/up links). But that would still require having the whole document in memory, and (through Javascript) just exposing parts of it at time. > Are these fixable? Is it worth fixing them? Or is it just that > prerendering to HTML simply is the better option and we should stop > worrying about it? I think it's always worthwhile to consider other ways. The CSS stylesheets are pretty far along already. There are some inherent limitations in what they'll be able to do on their own, but I there's a lot more that could be done in handling DocBook XML on the browser side with a combination of Javascript and CSS. As far as using browser-side XSLT with the DocBook XSLT stylesheets, I personally don't think that's ever going to be a practical solution. --Mike -- Michael(tm) Smith xmpp:smith@sideshowbarker.net irc://irc.freenode.net/mobile-web
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]