[XSL-LIST Mailing List Archive Home]
Re: Fw: Is there a way to define groups of templates ?
Subject: Re: Fw: Is there a way to define groups of templates ?|
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Fri, 25 Sep 1998 12:34:00 +0200
Paul Prescod <papresco@xxxxxxxxxxxxxxxx> Wrote:
>I see the issue now. I would suggest that the simplest way of solving it,
>without adding features to XSL is to use macros. Then the chapter w/
>general-toc mode could invoke the macro and so also could the section w/
>general-toc mode. Since the macro would not interfere with the mode, it
>would allow figures to "do the right thing" for the mode. I think that
>this solution is clearer to read than the one your propose...
[example showing repetition of the chapter rule, but containing just a macro
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. 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 :-)
>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.
>> > I think of a context as
>> >just a way of qualifying a template rule. The rule does not need, and
>> >probably should not have access to information about the context which
>> >gave rise to its calling. It's like a function in a program asking "who
>> >called me...and who called them...and who called them?" It strikes me as
>> >bad design.
>> But if we pursue this line of thought, doesn't it follow that the XSL
>> pattern is too strong? After all, it allows me to match on elements which
>> are contained in particular parents which are contained in ... and so on.
>That is asking about occurrence context: the structure of the input
>document. It is not asking about runtime call-context, the sequence of
>calls that gave rise to the document...
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.
> More general solutions
>to the "passing information down the stack" problem would also solve your
[allowing arguments to contexts, and using them in 'xsl:if' statements]
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.
>My point is that your solution only solves the problem for top-down
>processes. If I have the exact same problem in a situation that doesn't
>involve top-down processing, I am out of luck. That indicates a flaw in
>the solution. The macro and "mode alternative" solutions do not have that
>flaw. They don't depend on processing progessing in any particular
>direction. In my opinion, that puts them more in line with the "tao of
>XSL", which is designed to allow processing to progress in any direction.
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.
>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; you'd rather have two incomplete
simpler ones. I'd certainly be happier with the context-sensitive match
pattern; if the mode-alternative method is accepted, I can still do my
work - which is what's important, after all.
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?
Share & Enjoy,
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list