Re: Fw: Is there a way to define groups of templates ?

["Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>]

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