RE: [docbook-apps] Rethinking XSLT 2.0 design

["David Cramer" <dcramer@motive.com>]

And where the duplication can't be eliminated, the list would indicate the things you should consider eliminating from your local version of DocBook. For example, you would typically pick one of:

 * section/title or section/info/title 
 * recursive sections or sect1/sect2/sect3

Well...those are the only two that come to mind, but perhaps there are others. In any case, I think it would be helpful for new adopters if they were told upfront: 

1) Making a subset is very encouraged, though not required and 
2) When you make your subset, 
  a) eliminate one or the other of certain alternative legal ways of doing things to simplify things for your writers (then provide the list)
  b) eliminate elements you don't plan to use (or hide them in the editor, if your editor supports that)

I could even imagine a little DocBook subsetting tool where you make a few choices and then list some inlines you'll never use.

David

> -----Original Message-----
> From: Camille Bégnis [mailto:camille@neodoc.biz] 
> Sent: Thursday, May 27, 2010 7:11 AM
> To: docbook-apps@lists.oasis-open.org
> 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
> >
> >   
>