Subject: Re: Fw: Is there a way to define groups of templates ? From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Fri, 25 Sep 1998 21:02:31 +0200 |
Paul Prescod <papresco@xxxxxxxxxxxxxxxx> Wrote: >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. You are right - I combined it with the "alternative rendering" problem. Sorry. >> 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. Of course not. I just explained where my aversion to anything named "macro" has originated :-) XSL macros are fine. >> 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? I don't see how "processing" can be unrelated to the structure of the ouput document - I think this is the root of our disagreement. For example, if I want to generated a list, of necessity I have to have a rule of the form: <xsl:template match="something"> <ol> ... some processing command which will pass on the parts of the XML document which generate the content of the list - select is very useful here ... </ol> </xsl:template> As I see it, this directly reflects the structure of the output document - there's an "ol node" which "contains" list entries generated fron an arbitrary portion of the XML tree. It is the XML structure which is unrelated to the output. Maybe this is a difference in style, though it isn't clear to me how you'd achieve the same effect without hierarchical processing commands which tightly follow the structure of the output document. >> 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 :-) ... > >No, the macro feature is much more general than mode-sensitive match >patterns. I did place a smiley there :-) Of course macros are stronger, and necessary. >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". You are right. But why stop there? Suppose that it was valid to say: <xsl:set name="my-variable" value="some-value"> And later specify, in any pattern, "variable(my-variable)='some-value'". This would be legal in qualifiers, and would behave just like "attribute(name)='value'" except it would access the global variables table instead of the element's attributes. We'd also like 'xsl:set' to have an optional "global" modifier, which supresses reseting the variable to its original state once the current rule is done. The ability _not_ to restore the variable at the end of the rule gives raise to interesting possibilities... I'm _really_ starting to like this idea. It is less arbitrary then the approaches we've discussed so far; it is more powerful - you could emulate any of them easily enough; and it is certainly trivial to implement. Take any existing XSL processor. Add a global hash table, allow 'xsl:set' to manipulate it and 'variable()' to access it. Done. For example: <xsl:template match="book"> <xsl:set name="context" value="toc" scope="local"> <xsl:process-children> <xsl:set name="context" value="body" scope="local"> <xsl:process-children> </xsl:template> And then either: <xsl:template match="chapter"> <xsl:choose> <xsl:when test="variable(context)=toc"> ... </xsl:when> <xsl:when test="variable(context)=body"> ... </xsl:when> </xsl:choose> </xsl:template> Or even: <xsl:template match="chapter[variable(context)='toc']"> ... </xsl:template> <xsl:template match="chapter[variable(context)='body']"> ... </xsl:template> Do you see any disadvantage to this idea? Any chance for it? >> 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... I see what you mean. The problem is that if processing in some element specified a context, and somewhere in this processing we reach an element which is not a descendent of the original element, my method of specifying '@context//element-type' won't work. Using separate context patterns would work. So would using general state variables. >> >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... > >No... I still think this is a matter of taste and "religion" more then a technical one. Let's just agree to disagree on this one, OK? >> BTW, a point about implementation and "passing information down the stack". >>[possible implementation] > >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: ... You are right, of course. You need a list - actually, a stack - per element. Still not too difficult to implement. But I like the variables method much better... 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, James Clark |
Re: Fw: Is there a way to define gr, Paul Prescod | Date | Re: Fw: Is there a way to define gr, James Clark |
Month |