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:
>> Paul Prescod <papresco@xxxxxxxxxxxxxxxx> wrote:
>> > What if I have a
>> ><TOC/> empty element that indicates where the TOC is to go.


[...]

>> 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.
>
>No it isn't. The whole point of XSL is to allow authors to *decide* what
>is formatting and what is content. XSL should not force any particular
>choice on the author. You say that the position of a glossary in a book is
>just formatting. I say, that in the things I publish, it can be a vital
>part of the content. XSL is supposed to allow us both to make the choice
>for ourselves. (in fact, allowing this choice is what SGML was designed
>for, long before XSL was a gleam in anyone's eyes).


I agree that XSL should not make the choice for us. Currently, if you decide
to use TOC and INDEX nodes - a perfectly legitimate choice - then XSL, as it
stands today, allows you to do so. However, if you decide not to use such
nodes - something which should also be perfectly legitimate - XSL does not
allow you to do so. That's the issue.

[long example snipped...]

>> 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.
>
>Not at all. You put the chapter rule in a third context that can be
>invoked from either of the first two. Contexts can nest.

I don't see how. Lets generalize the example. Suppose I have two
process-children commands invoked for some element - P1 and P2. There are
three rules which apply to descendents of this element - R1, R2 and R3. Say
that R1 and R2 are alternative rules for one type of sub element and R3
matches another. The order of the sub elements in the output is significant
(say it is a list of some sort).

Now, if P1 would like to invoke R1 and R3, and P2 would like to invoke R2
and R3, there's no way you can do so in Eran's method without repeating R3,
since:

- You can't break P1 and P2 to separate processing commands, since the
output depends on the order of the sub elements. So 'select' and the like
won't help.

- If you give the same context in P1 and P2, you won't be able to specify R1
for P1 and R2 for P2.

- If you give different contexts to P1 and P2, you won't be able to share R3
for both P1 and P2.

In my example, P1 was the global TOC, and P2 was the detailed one; R1 and R2
controlled figures, with an "empty" R1; and R3 controlled the chapters.

I don't see how adding a third context would help. Admittedly I don't have
much experience with DSSSL - is there a trick to solve this problem?

>I've done this sort of processing with DSSSL for a year and a half now and
>have never wanted to do what you are describing.

I admittedly have just started working with XSL, but I immediately needed to
do the above :-)

> 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 match
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. I
can even match on very remote elements - for example, your own TOC node.
This isn't necessarily bad design - it just has to be used with care.

>Rather, it should be driven from the top-down. Does this function/template
>rule do what I need? If so, I will call it, and it should just do its
>thing without caring about the context of the call.


I agree as a matter of good style and design. But sometimes this just
doesn't work - or the match pattern language in XSL would have been much
weaker, for example.

>Plus, you haven't at all assuaged my fears that you understand that the
>context of a call to a rule is often *unrelated* to the context that the
>node exists in within the tree. Consider a cross-reference. In my DSSSL
>specifications, I often make a mode for cross-references. I may even make
>a special mode for cross references that originate in the back matter
>(let's say). So the context of the call does matter, but is completely
>unrelated to the tree context!


Of course the context _might_ be unrelated to the structure, and it often
isn't. A cross reference is a very good example, as would automatic index
generation. This does not rule out cases where there _is_ a relation. Using
the extended match pattern method, you can have it both ways. Using the
simple context pattern method, you can't. Should XSL decide this for us, or
should it support both approaches?

Share & Enjoy,

    Oren Ben-Kiki


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