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

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

Paul Prescod <papresco@xxxxxxxxxxxxxxxx> wrote:
>Oren Ben-Kiki wrote:
>> 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.

Yes. Sorry about the sloppy terminology.

>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.

This is exactly what the suggestion tries to achive - to allow to freely mix
statements about the document structure with statements about the current
computation. This capability is missing from the current draft, and is
necessary for real-life conversions (a TOC is just an example).

> What if I have a
><TOC/> empty element that indicates where the TOC is to go.

I assume you refer to the XML document tree. Well, as I understand the
purpose of XML/XSL, you shouldn't. The TOC element you describe is used just
for controlling formatting, and XML should be used just to specify content.
XSL should be used to specify formatting.

> 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.


You could. But in this approach, you force whoever writes the XML document
to provide the contexts required by the particular XSL used. For example, if
I had one XSL which specified an index, and another which specified a table
of content, the XML writer would have to include a TOC tag and an INDEX tag
in advance. Then someone would come with an XSL containing a glossary, or a
per-chapter table of content, and so on... We want to avoid all that. That's
the whole point of using XSL.

>> - 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 didn't make myself clear. Currently, a pattern contains a path of
element-patterns, each matching a single element of the original XML tree.
What I propose is that it would be possible to qualify each element pattern
with a context, in which case it would match the element only within a
processing command specified in a rule which matched this element and which
specified that context. As a special case, if the qualified element pattern
does not contain an empty "normal" element pattern, it would match any
element type. '@toc' is therefore equivalent to '*@toc', if regular
expressions were valid element patterns. In fact, if they were, I wouldn't
have had to specify this special case.

The difference between my suggestion and Eran's is exactly in that it is
possible to mix structural and processing patterns. It also makes it
possible to naturally nest contexts. For example, suppose you have a complex
document, and you want a general TOC at the beginning, plus a detailed TOC
at the beginning of each section. In my method, you could have the following
rules:

<xsl:template match="/">
Generate global TOC:
<process-children context="toc">
Generate body:
<proecss-children context="body">
</xsl:template>

<xsl:template match="@body//section">
Generate detailed per-section TOC:
<process-children context="toc">
Generate section body:
<proecss-children context="body">
</xsl:template>

<xsl:template match="@toc//section">
Generate the entries for the section in the general TOC:
<process-children context="toc">
</xsl:template>

Note that the detailed per-section TOC uses the same 'toc' context as the
global toc. This allows us to write:

<xsl:template match="@toc//chapter">
Will appear in both the general TOC and the detailed per-section TOC.
</xsl:template>

So far, we could have used Eran's suggestion using a 'context="toc"' or
'context="body"' in addition to the 'match="..."' pattern. However, the
following would not have been possible:

<xsl:template match="@body//section@toc//figure>
Will appear only in the detailed per-section TOC.
</xsl:template>

This rule is impossible to express using Eran's notation. Note that there is
a workaround. You can define two contexts, 'general-toc' and 'section-toc'.
The figure rule will only be triggered by the latter. If you do that,
however, you'd have to specify the chapter rule twice, once per context. Or,
you'd have to specify that the 'context="..."' pattern allows specifying
multiple contexts, as in 'context="general-toc|section-toc"'. This is a
first step on a slippery slope of which features to include in the context
patterns.

The way I see it, it is better to add a small extension to the existing
match pattern syntax, instead of defining a new context pattern syntax.
Anything that can be done using a separate context pattern can also be done
in the extended match pattern. You also avoid the need of defining the
relationship between the context pattern and the match pattern. Expressing
relationships between structure and processing becomes natural (as in the
figure rule above - "this rule applies in the table of contents generated
for each section, which is included in the document's body").

>> 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".


I believe that when something like a processing context is added, it would
serve as a barrier against a host of featutes meant to address the lack for
specific cases. Any new such feature would require someone would to make a
convincing case that the additional complexity of the language is worth it,
given that the same effect may be achieved using the general feature. It may
even be that certain features would be defined as a shorthand completely
equivalent to using the general feature in a particular manner (and may
actually be implemented in this way).

As for the 'select' feature, I suspect it is useful enough to warrant the
additional language complexity. But the case should be made by comparing the
alternative specifications, checking whether 'select' is used/needed often
enough to warrant the feature, and so on.

Share & Enjoy,

    Oren Ben-Kiki


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list