Re: [docbook-apps] Rethinking XSLT 2.0 design

[Camille Bégnis <camille@neodoc.biz>]

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