Re: Fw: Is there a way to define groups of templates ?
Oren Ben-Kiki wrote: > > Nice trick. It would do the job, but is a bit of a kludge. You still have to > repeat the chapter rule for each context, even if it just contains a macro > call. And a single macro now contains all the alternative renderings, > selected by an 'xsl:if', instead of having each in a separate rule and > specified decleratively. I think that you are combining two different solutions to the problem. My first solution did not use xsl:if. > Admittedly I'm not too fond of the macro feature - > it hints of a lack in the language. A matter of taste, possibly, with vivid > memories of the effect of macros on the C language :-) XSL macros are nothing like C macros. They are a code reuse mechanism: like C functions. Anyhow, you cannot replace macros with any other feature. Let's say that 1/10th of this rule always has identical code with 1/5th of that one. How can you share that code without macros? For instance, some portion of the code that sets up a section may be identical to the code that sets up a chapter. > >On the other hand, I see no particular problem with your solution of > >allowing modes to be specified as alternatives. I do not believe it is a > >slippery slope. It would just be a notational convenience for doing the > >equivalent of the macro trick. > > If, for example, regular expressions are ever added to the match pattern, > there would be a strong case for adding them to the context pattern as well. > Now that is necessarily a bad thing; again it is a matter of taste. No, you can't use regular expressions in a mode pattern, because there is no "string" to match. You could allow mode patterns, but the argument against that is quite strong: you shouldn't need to know about your parent or grandparent mode. It's simply bad design. In other words, I don't see this feature creep as meaningful. > The way I think of it, there's the structure of the input XML document, and > there's the structure of the output (HTML?) document. Both are tree > structures. XSL (should) allow converting one tree to the other. What you > see as "computational" - depending on nested call contexts, I see as > "structural" - depending on the structure of the output document. The only > way I can express this structure is via processing calls, but it still is a > structural dependency. If there is a better way to specify this type of > constraints as structural, I'm all for it. The nesting of modes is only a weak reflection of the output tree structure. I could have an XSL stylesheet that goes down twenty levels without producing anything, and then produces a full document. Input, output and processing order are all more or less unrelated. Even if processing order and output structure were the same, how would that suggest that a single pattern language should address both input tree and output tree? > Yes, that would also do the trick. On the other hand, maybe we could get rid > of macros and arguments altogether if we had context-sensitive match > patterns :-) It just goes to show one should be very careful when selecting > the feature set for computer languages. We don't want to end up with a PL/I > or C++ type fiasco - all possible features thrown in together. No, the macro feature is much more general than mode-sensitive match patterns. Also, your passing down of mode names is just a special case of my passing down "anything" (arbitrary arguments). Your mode names are attached to particular ancestors, but I can emulate that too. I can have args named "most-recent-section-mode". > I'm afraid you lost me here. Could you give an example of a non-top-down > rule set expressed using macros and mode alternatives, which can't be > trivially converted to context-sensitive match patterns? Of the top of my > head, I can't think of any. Well, it's a little bit of a challenge, because the problem you describe is rare. Let me just twist your own example around. One of the benefits proclaimed for XML is data reuse? Consider a situation where many books occur in a single XSL text stream, with chapters shared betgween them. One way to do that is like this: <BOOKS> <BOOK> <CHAPTER><TITLE>Some Title</TITLE> <P>Some content.</P></CHAPTER> <CHAPTER ID="reuable"><TITLE>Some Title</TITLE> <P>Some content.</P></CHAPTER> </BOOK> <BOOK> <CHAPTER><TITLE>Some Title</TITLE> <P>Some content.</P></CHAPTER> <CHAPTER-REF IDREF="reusable"/> </BOOK> </BOOKS> The last chapter is a repeat of an earlier one, from a similar book. (obviously these aren't novels, they are probably technical manuals) The XSL stylesheet is supposed to process the chapter-ref by processing the element that it references: (in a completely different part of the document). Now imagine we have your same TOC problem. I've decoupled the structure of the computation from the context of the processed element. Your syntax will be meaningless. It would be even more clear that it would be meaningless if I moved the chapter out of a book (which at least has the SAME structure as the original context, even if a different instance of it) and moved it into a special holding pen for reusable chapters. > >Your own "mode alternative" idea IS in sync with the "tao of XSL." I'm not > >sure why you discarded it. > > As I said, it is a matter of taste; I'd rather have a single, slightly more > complex, but complete, pattern language; No, what you are proposing is a single pattern language that merges two unrelated concepts. > you'd rather have two incomplete simpler ones. No, I'd rather have two complete languages that address a single part of the system. > BTW, a point about implementation and "passing information down the stack". > Today in each XSL processor there's some piece of code which compares a > concrete path (built of element types) with a match pattern. In order to > support context-sensitive match patterns, "all" you need to do is to keep in > the concrete path an optional context for each element, and enhance the > comparison algorithm accordingly. The contexts are attached to the concrete > path elements when processing commands are invoked, and detached when they > are done. It seems like a rather minor implementation change - maybe someone > who has actually written an XSL processor could comment on that? The same node can be processed twice (or thrice!) in the same computation. As long as you are in a different mode each time, you won't cause an infinite loop. So you need a LIST of modes to attach to each node. For example: <xsl:template match="section" mode="body"> <xsl:process mode="one" select="."> </xsl:template> <xsl:template match="section" mode="one"> <xsl:process mode="two" select="."> </xsl:template> <xsl:template match="section" mode="two"> <xsl:process mode="three" select="."> </xsl:template> <xsl:template match="section" mode="three"> BOO! </xsl:template> Once again, your syntax can't handle this properly because the processing structure is radically different from the input structure. Paul Prescod - http://itrc.uwaterloo.ca/~papresco How many of the Congresspeople who voted for the CDA do you suppose also voted to release the report that reads like a borderline por- nographic dime-store romance written by a Texas preacher's son? - Keith Dawson, TBTF http://www.tbtf.com/archive/09-14-98.html http://www.tbtf.com/resource/hypocrites.html 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