Subject: Fw: Is there a way to define groups of templates ? From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Wed, 23 Sep 1998 12:44:43 +0200 |
Paul Prescod <papresco@xxxxxxxxxxxxxxxx> wrote: >Oren Ben-Kiki wrote: >> Here's a suggestion which requires just a minor change to the draft, is very >> powerful, and is easy to implement: >> >> - Allow a context attribute in the processing commands. For example, >> <xsl:process-children context="toc"> > >Okay, that's simple enough. > >> - Allow suffixing a tag name in a pattern with a context. For example, >> <xsl:template match="book@toc//chapter"> would match a chapter node which >> has a book node as an ancestor, but only inside a process command _in a rule >> matching that book node_ which specified the "toc" context. > >The XSL spec. doesn't use or define the word tag (except as part of >"start-tag"). I think that you mean element type name. Yes. Sorry about the sloppy terminology. >I find your idea a >little confusing. book//chapter is a statement of the structure of the >document, not a statement about the current computation or about the >series of process rules that lead to this computation. This is exactly what the suggestion tries to achive - to allow to freely mix statements about the document structure with statements about the current computation. This capability is missing from the current draft, and is necessary for real-life conversions (a TOC is just an example). > What if I have a ><TOC/> empty element that indicates where the TOC is to go. I assume you refer to the XML document tree. Well, as I understand the purpose of XML/XSL, you shouldn't. The TOC element you describe is used just for controlling formatting, and XML should be used just to specify content. XSL should be used to specify formatting. > Then the >"context hierarchy" would be completely unrelated to the element tree. For >instance I might go UP from the TOC element to the DOC element and then >search for all CHAPTER elements within it. 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. >> - Allow specifying just the context, without a tag, in a pattern. For >> example: match="@toc//chapter" would match a chapter node, but only inside >> _any_ process command which specified the "toc" context. > >This seems to handle the case I described above. In fact, it is equivalent >to Eran Pe'er's proposal, which is in turn equivalent (more or less) to >DSSSL modes. It would also seem to subsume the features of your first >version above, so why not just have this? I didn't make myself clear. Currently, a pattern contains a path of element-patterns, each matching a single element of the original XML tree. What I propose is that it would be possible to qualify each element pattern with a context, in which case it would match the element only within a processing command specified in a rule which matched this element and which specified that context. As a special case, if the qualified element pattern does not contain an empty "normal" element pattern, it would match any element type. '@toc' is therefore equivalent to '*@toc', if regular expressions were valid element patterns. In fact, if they were, I wouldn't have had to specify this special case. The difference between my suggestion and Eran's is exactly in that it is possible to mix structural and processing patterns. It also makes it possible to naturally nest contexts. For example, suppose you have a complex document, and you want a general TOC at the beginning, plus a detailed TOC at the beginning of each section. In my method, you could have the following rules: <xsl:template match="/"> Generate global TOC: <process-children context="toc"> Generate body: <proecss-children context="body"> </xsl:template> <xsl:template match="@body//section"> Generate detailed per-section TOC: <process-children context="toc"> Generate section body: <proecss-children context="body"> </xsl:template> <xsl:template match="@toc//section"> Generate the entries for the section in the general TOC: <process-children context="toc"> </xsl:template> Note that the detailed per-section TOC uses the same 'toc' context as the global toc. This allows us to write: <xsl:template match="@toc//chapter"> Will appear in both the general TOC and the detailed per-section TOC. </xsl:template> So far, we could have used Eran's suggestion using a 'context="toc"' or 'context="body"' in addition to the 'match="..."' pattern. However, the following would not have been possible: <xsl:template match="@body//section@toc//figure> Will appear only in the detailed per-section TOC. </xsl:template> 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. Or, you'd have to specify that the 'context="..."' pattern allows specifying multiple contexts, as in 'context="general-toc|section-toc"'. This is a first step on a slippery slope of which features to include in the context patterns. The way I see it, it is better to add a small extension to the existing match pattern syntax, instead of defining a new context pattern syntax. Anything that can be done using a separate context pattern can also be done in the extended match pattern. You also avoid the need of defining the relationship between the context pattern and the match pattern. Expressing relationships between structure and processing becomes natural (as in the figure rule above - "this rule applies in the table of contents generated for each section, which is included in the document's body"). >> I suspect such a feature would reduce the need for other advanced features. >> For example, the "select" functionality could be implemented using a context >> and a separate rule. > >That's true, but I think that you will find that just as often the >functionality is more conveniently and clearly represented as a "select". I believe that when something like a processing context is added, it would serve as a barrier against a host of featutes meant to address the lack for specific cases. Any new such feature would require someone would to make a convincing case that the additional complexity of the language is worth it, given that the same effect may be achieved using the general feature. It may even be that certain features would be defined as a shorthand completely equivalent to using the general feature in a particular manner (and may actually be implemented in this way). As for the 'select' feature, I suspect it is useful enough to warrant the additional language complexity. But the case should be made by comparing the alternative specifications, checking whether 'select' is used/needed often enough to warrant the feature, and so on. Share & Enjoy, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Is there a way to define groups, Paul Prescod | Thread | Re: Fw: Is there a way to define gr, Paul Prescod |
Re: XSL Trans, Paul Prescod | Date | Re: XSL Trans, Dave Peterson |
Month |