[docbook-apps] Re: Rethinking XSLT 2.0 design
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 normalization does recently, but the info/title case arises from a desire to make life easier for authors. If all you need on a section is a title (and/or subtitle and titleabbrev), being required to put in the info wrapper is a burden that I don't think authors would appreciate. But if you want title, pubdate, author, copyright, etc. then you do have to put in the info wrapper. At least in DocBook V5.0, you can only have the title in one place or the other. In earlier versions of DocBook, it was schema-valid to have multiple titles (that might not necessarily be the same). 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... You could decide that, but it would be wrong :-) Be seeing you, norm -- Norman Walsh n...@nwalsh.com | The human race consists of the http://www.oasis-open.org/docbook/ | dangerously insane and such as are Chair, DocBook Technical Committee | not.--Mark Twain pgpE3MyI8qusV.pgp Description: PGP signature
[docbook-apps] Re: Rethinking XSLT 2.0 design
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 think that one's just fine the way it is. * recursive sections or sect1/sect2/sect3 Yeah, it probably makes sense to pick one of those. 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) Sure, but I'm not sure how to make that advice very concrete given that every customization is likely to be pretty unique. I could even imagine a little DocBook subsetting tool where you make a few choices and then list some inlines you'll never use. Yes, something like what the TEI folks call the Pizza Chef, http://www.tei-c.org/pizza.html, would be handy. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | We ought not to heap reproaches on http://www.oasis-open.org/docbook/ | old age, seeing that we all hope Chair, DocBook Technical Committee | to reach it.-- Bion pgpVlTWnLAGJM.pgp Description: PGP signature
[docbook-apps] Re: Rethinking XSLT 2.0 design
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 that profiling should be default in XSLT 2.0 stylesheets. Also I'm now working on transclusions use-cases document for DocBook TC and in DocBook specific transclusion mechanisms is emerging in my head. This means another pass over the document. I agree that it should be possible to do all those things, and that they should be easy. I'm not sure I agree that they should all always happen whenever you process a document. In an, *ahem*, database context, for example, I can imagine wanting to factor some of those processes in different ways. :-) I'm not sure whether normalization was good or bad, but I think that its processing burden is not so high compared to stylesheets load time. Yeah. Maybe. In some contexts. :-) 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). What about not supporting DB4 in XSLT 2.0 stylesheets? It will simplify things and users can always run their own DB4-DB5 process before stylesheets are applied. 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 times. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Ignorance is a precious commodity: http://www.oasis-open.org/docbook/ | once it's gone, you can't get it Chair, DocBook Technical Committee | back. pgptJsDCSieLu.pgp Description: PGP signature
Re: [docbook-apps] Re: Rethinking XSLT 2.0 design
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 times. That sounds reasonable. Moreover in XSLT 2.0 doing so is much more easier then in XSLT 1.0. Jirka -- -- Jirka Kosek e-mail: ji...@kosek.cz http://xmlguru.cz -- Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing -- OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member -- signature.asc Description: OpenPGP digital signature
[docbook-apps] Re: Rethinking XSLT 2.0 design
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 experiments. Thanks for clarifying that you'll be working on these stylesheets again, especially in light of Jirka's Google Summer of Code project. I think your ideas about dropping normalization, segmenting the stylesheets into discrete processing chunks rather than always creating a massive, unified stylesheet, and potentially not seamlessly handling DB4 are all prudent and justified. What I'd like to understand is your current thinking on the top three goals of the XSLT2 reimplementation itself. What are they? I've written about that a little bit, for example: http://norman.walsh.name/2004/07/27/titlepages but in terms of top three goals, I'd have to say: 1. Move to XSLT 2.0 techniques to both streamline and simplify the stylesheets but also to make them easier to customize and extend. 2. They've grown by accretion for a decade or so, it's time they got a little top-down refactoring and organization. 3. They should be better documented and there should be tests for everything. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Where it is permissible both to http://www.oasis-open.org/docbook/ | die and not to die, it is an abuse Chair, DocBook Technical Committee | of valour to die.-- Mencius pgpc4aGhhB3kU.pgp Description: PGP signature
