[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Rethinking XSLT 2.0 design
Hi Norm and all, My opinion on the subject is that we should try listing the cases (like /section/info/title) why the first step is required. And then see if the schema could not be simplified to make that first step unnecessary. I have found that this kind of choice is often confusing for the end user (the writer). Notwithstanding the processing issues. You can very well decide to process differently /section/info/title and /section/title while they are theoretically the same "thing" according to the schema... Sorry I don't help you much for your current problem :-) Camille. On 27/05/2010 13:59, Norman Walsh wrote: > Hi folks, > > I'm going to be turning my hands to the XSLT 2.0 stylesheets for > DocBook again soon, partly with an eye towards making them more > production ready, partly to try a few experiments. > > When I set out on the XSLT 2.0 reimplementation, I had in mind a > design where there'd be a "normalization" phase that does some cleanup > followed by a processing phase that does the actual work. > > For example, normalization turns > > <section><title>foo</title>... > > into > > <section><info><title>foo</title></info>... > > so that subsequent processing can know that the title is > section/info/title. > > After several years of experience, I've come to the conclusion that > that was a mostly bad idea. > > 1. It's very expensive. The entire document gets processed at least > twice. While the idea of simplifying the "downstream" design seemed > very attractive, I think the cost is too high. > > 2. It doesn't actually simplify things. Oh, in theory it does, but in > practice, it's harder to debug because the document you're looking at > isn't actually the one being styled. > > 3. That problem extends to the actual users as well, if something goes > wrong, the error messages don't reflect the document that the user > actually sent to the stylesheets. > > 4. I made a DB4 to DB5 conversion phase part of that normalization, > and that makes the problems even worse (three phases, an even broader > disconnect). > > So my initial plan is to look at breaking things down so that the > processing is more direct. I'll probably keep the normalization phases > around as separate stylesheets. > > I reserve the right to change my mind again when I get underway :-) > > Comments most welcome. > > Be seeing you, > norm > >
begin:vcard fn:Camille Begnis n:Begnis;Camille org:NeoDoc adr:;;5 rue de la Touloubre;Venelles;;13770;France email;internet:camille@neodoc.biz tel;work:+33.9.54.96.99.55 tel;fax:+33.9.59.96.99.55 tel;cell:+33.6.33.15.10.23 url:http://www.neodoc.biz version:2.1 end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]