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

Subject: Re: Is there a way to define groups of templates ?
From: Paul Prescod <papresco@xxxxxxxxxxxxxxxx>
Date: Sat, 19 Sep 1998 11:05:31 -0500
Oren Ben-Kiki wrote:
> > There will almost certainly be something like this in the next version
> > of the working draft.
> Is there any idea - even a preliminary one - as to what form it would take?

Well, the spec. says:

"Issue (modes): How should the functionality of DSSSL modes be provided?
Should nested template rules be used for this? Is there a way of getting
source elements to appear in multiple places in the output that can be
implemented in a single pass?"

> Here's a suggestion which requires just a minor change to the draft, is very
> powerful, and is easy to implement:
> - Allow a context attribute in the processing commands. For example,
> <xsl:process-children context="toc">

Okay, that's simple enough.
> - Allow suffixing a tag name in a pattern with a context. For example,
> <xsl:template match="book@toc//chapter"> would match a chapter node which
> has a book node as an ancestor, but only inside a process command _in a rule
> matching that book node_ which specified the "toc" context.

The XSL spec. doesn't use or define the word tag (except as part of
"start-tag"). I think that you mean element type name. I find your idea a
little confusing. book//chapter is a statement of the structure of the
document, not a statement about the current computation or about the
series of process rules that lead to this computation. What if I have a
<TOC/> empty element that indicates where the TOC is to go. Then the
"context hierarchy" would be completely unrelated to the element tree. For
instance I might go UP from the TOC element to the DOC element and then
search for all CHAPTER elements within it.

> - Allow specifying just the context, without a tag, in a pattern. For
> example: match="@toc//chapter" would match a chapter node, but only inside
> _any_ process command which specified the "toc" context.

This seems to handle the case I described above. In fact, it is equivalent
to Eran Pe'er's proposal, which is in turn equivalent (more or less) to
DSSSL modes. It would also seem to subsume the features of your first
version above, so why not just have this?

> I suspect such a feature would reduce the need for other advanced features.
> For example, the "select" functionality could be implemented using a context
> and a separate rule.

That's true, but I think that you will find that just as often the
functionality is more conveniently and clearly represented as a "select".

 Paul Prescod  -

The past is inaccurate. Whoever lives long enough knows how much what he
had seen with his own eyes becomes overgrown with rumor, legend a
magnifying or belittling hearsay. "It was not like that at all!" -- 
he would like to exclaim, but will not, for they would have seen only 
his moving lips without hearing his voice. - Czeslaw Milosz (translated)

 XSL-List info and archive:

Current Thread