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

[Eric Johnson <emjohnso@progress.com>]

On 3/12/2010 10:51 AM, Szabó Árpád Zoltán wrote:
> 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
>
>    
That looks pretty slick.