Re: Is there a way to define groups of templates ?
Oren Ben-Kiki wrote: > > > There will almost certainly be something like this in the next version > > of the working draft. > > Is there any idea - even a preliminary one - as to what form it would take? Well, the spec. says: "Issue (modes): How should the functionality of DSSSL modes be provided? Should nested template rules be used for this? Is there a way of getting source elements to appear in multiple places in the output that can be implemented in a single pass?" > 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. 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. What if I have a <TOC/> empty element that indicates where the TOC is to go. 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. > - 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 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". Paul Prescod - http://itrc.uwaterloo.ca/~papresco The past is inaccurate. Whoever lives long enough knows how much what he had seen with his own eyes becomes overgrown with rumor, legend a magnifying or belittling hearsay. "It was not like that at all!" -- he would like to exclaim, but will not, for they would have seen only his moving lips without hearing his voice. - Czeslaw Milosz (translated) XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format