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

Subject: Re: Fw: Is there a way to define groups of templates ?
From: Paul Prescod <papresco@xxxxxxxxxxxxxxxx>
Date: Fri, 25 Sep 1998 08:51:53 -0500
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


Current Thread