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

smime.p7s



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