[docbook-apps] Rethinking XSLT 2.0 design

2010-05-27 Thread Norman Walsh
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

Re: [docbook-apps] Rethinking XSLT 2.0 design

2010-05-27 Thread Camille Bégnis
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

RE: [docbook-apps] Rethinking XSLT 2.0 design

2010-05-27 Thread David Cramer
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

Re: [docbook-apps] Rethinking XSLT 2.0 design

2010-05-27 Thread Jirka Kosek
Norman Walsh wrote: 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. I think that multiple passes over document are necessary anyway -- I think that profiling

[docbook-apps] Re: Rethinking XSLT 2.0 design

2010-05-27 Thread Norman Walsh
Camille Bégnis cami...@neodoc.biz writes: 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 haven't reviewed all the things that

[docbook-apps] Re: Rethinking XSLT 2.0 design

2010-05-27 Thread Norman Walsh
David Cramer dcra...@motive.com writes: 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 I don't agree. I

[docbook-apps] Re: Rethinking XSLT 2.0 design

2010-05-27 Thread Norman Walsh
Jirka Kosek ji...@kosek.cz writes: 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. I think that multiple passes over document are necessary anyway -- I think

RE: [docbook-apps] Rethinking XSLT 2.0 design

2010-05-27 Thread David Cramer
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. That's true. One useful thing would be to have a debug switch which that causes the xslts to spit out

Re: [docbook-apps] Re: Rethinking XSLT 2.0 design

2010-05-27 Thread Jirka Kosek
Norman Walsh wrote: Yes, I think that's probably the right answer. More generally, I think I want to decompose all the functionally separate phases. We might want to provide a stylesheet that does all the steps, but I (think I) also want the ability to apply the different phases at different

Re: [docbook-apps] Rethinking XSLT 2.0 design

2010-05-27 Thread Keith Fahlgren
Hi Norm, On Thu, May 27, 2010 at 4:59 AM, Norman Walsh n...@nwalsh.com wrote: 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. Thanks for clarifying that you'll

[docbook-apps] Re: Rethinking XSLT 2.0 design

2010-05-27 Thread Norman Walsh
Keith Fahlgren abdela...@gmail.com writes: Hi Norm, On Thu, May 27, 2010 at 4:59 AM, Norman Walsh n...@nwalsh.com wrote: 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