DocBook transformation by browsers' xslt engine

[Szabó Árpád Zoltán<szabo.arpad.zoltan@gmail.com>]

User experience first. Developer convenience close second.

I believe it's not hard to see the reason in these sentences. I've 
borrowed (and simplified) them from Google Web Toolkit's design 
principles, which can be roughly defined as a client side (i.e. 
JavaScript) web application framework.

Docbook's web presentation nowadays relies on the chunked html files 
with a table of contents (besides bightml), which can be arranged into a 
html frameset, and main theme of its working is this: user clicks on 
table of contents entry, browser gets html document from server and display.

I'm wondering about an another theme of working: user clicks on table of 
contents entry, browser applies xslt stylesheet to the previously 
downloaded docbook xml file, and display.

The potential of this method relies in the fact that there's no need for 
browser-server communication - after the stylesheet and docbook 
documents are loaded. Which is the disadvantage of the method of course: 
user needs to wait for the whole document to download even if all she 
needs is a part or a chapter only.

I say potential, because some other factors need to be considered to 
make it work: the xslt transformation needs to be actually faster then 
response from the server.

Then there's of course the question of browser compatibility of xslt 
processing. In this regard, I've prepared a small proof of concept 
example, using Google Web Toolkit's architecture. It's available at:

http://docbook-publishing.appspot.com/DocBookPublishing.html

The files there are simple but valid DocBook documents, the table of 
contents are custom-made, so is the little xslt file which the processor 
applies every time the user clicks on a table of contents item.

I've tried it in several different browsers ( recent versions of Mozilla 
Firefox, Internet Explorer, Opera, Safari, Google Chrome ), and it seems 
to work. An my impression is that it's really fast. (Again, I don't 
count the initial load time of the document - I believe this can be made 
acceptable with proper progress indication.)

Now the next step would be to apply this on arbitrary DocBook documents. 
I can see some problems to solve. First, table of contents generation. 
This should be very similar to that of HTMLHelp's TOC. I'm wondering 
whether the "links" to different parts of the document could be xpath 
path definitions instead of id-s of tags. This way those parts of the 
document could be referred too, which don't hold id attribute (id 
generation not being an option here: I don't think we should assign id-s 
to the document's parts at this point).

Second, html formatting of selected parts. Main problem to solve here, 
that I can see, is that for the sake of the xslt processors, the 
stylesheet should be a single file.  (Talking about developer 
convenience, huh?) (Browsers' xslt processors can handle loading of 
imported stylesheets, but something prevents it from loading documents 
dynamically, around i18n. Maybe just the paths, I haven't investigated 
thoroughly yet.) And if I concatenate all the files required to html 
transformation, the size is around 1.4 megabyte.

So this is where I'm at now. Thanks for following my little train of 
thoughs, I'm really interested in your opinions. (Or tell me if I've 
invented the wheel or hot water or something like that, or it worths 
nothing because...)

Yours,
Arpad

----
Szabó Árpád Zoltán
from Hungary