Re: [docbook-apps] DocBook transformation by browsers' xslt engine

[Sam Fischmann <sam.fischmann@gmail.com>]

This is really interesting and looks pretty cool, but I am curious what the advantages are of making the browser perform the transformation, instead of:

• Doing a chunked HTML transformation beforehand and putting the HTML files on a server.
• Using javascript to download and cache the HTML files locally on the client when the user loads your page.

Then you have the advantage of a local cache without the disadvantage of worrying about transform time, browser XSLT compatibility, transforming arbitrary documents, and difficulty of adapting the DocBook stylesheets to work in this special use case. The plain old HTML linking mechanism would work fine, too, provided that you hijack click events to perform a lookup in your local cache before requesting the file from the server.

-Sam

 

-----Original Message-----

From: Szabó Árpád Zoltán [mailto:szabo.arpad.zoltan@gmail.com] 

Sent: Friday, March 12, 2010 7:51 AM

To: docbook-apps@lists.oasis-open.org

Subject: [docbook-apps] DocBook transformation by browsers' xslt engine

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

---------------------------------------------------------------------

To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org

For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org