Subject: Re: Fw: Is there a way to define groups of templates ? From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Thu, 24 Sep 1998 19:33:00 +0200 |
Paul Prescod <papresco@xxxxxxxxxxxxxxxx> wrote: >Oren Ben-Kiki wrote: >> Paul Prescod <papresco@xxxxxxxxxxxxxxxx> wrote: >> > What if I have a >> ><TOC/> empty element that indicates where the TOC is to go. [...] >> You could. But in this approach, you force whoever writes the XML document >> to provide the contexts required by the particular XSL used. For example, if >> I had one XSL which specified an index, and another which specified a table >> of content, the XML writer would have to include a TOC tag and an INDEX tag >> in advance. Then someone would come with an XSL containing a glossary, or a >> per-chapter table of content, and so on... We want to avoid all that. That's >> the whole point of using XSL. > >No it isn't. The whole point of XSL is to allow authors to *decide* what >is formatting and what is content. XSL should not force any particular >choice on the author. You say that the position of a glossary in a book is >just formatting. I say, that in the things I publish, it can be a vital >part of the content. XSL is supposed to allow us both to make the choice >for ourselves. (in fact, allowing this choice is what SGML was designed >for, long before XSL was a gleam in anyone's eyes). I agree that XSL should not make the choice for us. Currently, if you decide to use TOC and INDEX nodes - a perfectly legitimate choice - then XSL, as it stands today, allows you to do so. However, if you decide not to use such nodes - something which should also be perfectly legitimate - XSL does not allow you to do so. That's the issue. [long example snipped...] >> This rule is impossible to express using Eran's notation. Note that there is >> a workaround. You can define two contexts, 'general-toc' and 'section-toc'. >> The figure rule will only be triggered by the latter. If you do that, >> however, you'd have to specify the chapter rule twice, once per context. > >Not at all. You put the chapter rule in a third context that can be >invoked from either of the first two. Contexts can nest. I don't see how. Lets generalize the example. Suppose I have two process-children commands invoked for some element - P1 and P2. There are three rules which apply to descendents of this element - R1, R2 and R3. Say that R1 and R2 are alternative rules for one type of sub element and R3 matches another. The order of the sub elements in the output is significant (say it is a list of some sort). Now, if P1 would like to invoke R1 and R3, and P2 would like to invoke R2 and R3, there's no way you can do so in Eran's method without repeating R3, since: - You can't break P1 and P2 to separate processing commands, since the output depends on the order of the sub elements. So 'select' and the like won't help. - If you give the same context in P1 and P2, you won't be able to specify R1 for P1 and R2 for P2. - If you give different contexts to P1 and P2, you won't be able to share R3 for both P1 and P2. In my example, P1 was the global TOC, and P2 was the detailed one; R1 and R2 controlled figures, with an "empty" R1; and R3 controlled the chapters. I don't see how adding a third context would help. Admittedly I don't have much experience with DSSSL - is there a trick to solve this problem? >I've done this sort of processing with DSSSL for a year and a half now and >have never wanted to do what you are describing. I admittedly have just started working with XSL, but I immediately needed to do the above :-) > I think of a context as >just a way of qualifying a template rule. The rule does not need, and >probably should not have access to information about the context which >gave rise to its calling. It's like a function in a program asking "who >called me...and who called them...and who called them?" It strikes me as >bad design. But if we pursue this line of thought, doesn't it follow that the XSL match pattern is too strong? After all, it allows me to match on elements which are contained in particular parents which are contained in ... and so on. I can even match on very remote elements - for example, your own TOC node. This isn't necessarily bad design - it just has to be used with care. >Rather, it should be driven from the top-down. Does this function/template >rule do what I need? If so, I will call it, and it should just do its >thing without caring about the context of the call. I agree as a matter of good style and design. But sometimes this just doesn't work - or the match pattern language in XSL would have been much weaker, for example. >Plus, you haven't at all assuaged my fears that you understand that the >context of a call to a rule is often *unrelated* to the context that the >node exists in within the tree. Consider a cross-reference. In my DSSSL >specifications, I often make a mode for cross-references. I may even make >a special mode for cross references that originate in the back matter >(let's say). So the context of the call does matter, but is completely >unrelated to the tree context! Of course the context _might_ be unrelated to the structure, and it often isn't. A cross reference is a very good example, as would automatic index generation. This does not rule out cases where there _is_ a relation. Using the extended match pattern method, you can have it both ways. Using the simple context pattern method, you can't. Should XSL decide this for us, or should it support both approaches? Share & Enjoy, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Fw: Is there a way to define gr, Paul Prescod | Thread | Re: Fw: Is there a way to define gr, Paul Prescod |
Re: Fw: Is there a way to define gr, Paul Prescod | Date | Re: Fw: Is there a way to define gr, Paul Prescod |
Month |