Re: Processing Modes...

Subject: Re: Processing Modes...
From: Geoff Nolan <gjn@xxxxxxxxxxxxxx>
Date: Mon, 18 Jan 1999 13:40:56 +1100
Dear XSL-ers,

Having read the spec more carefully (and the PDF version is MUCH
easier to read than just printing from Netscape :), I can now see
that templates in the local stylesheet always take precedence over
imports. This answers one of my earlier reservations.

The removal of specificity as a consideration still causes me
concern however. It is a very common requirement that elements need
to be mapped differently depending on context. What I now see is
that every template which could POSSIBLY match a given element MUST
be given an explicit priority. This is IMHO both unaesthetic and
impractical in real life stylesheeting.

I do indeed see that the XSL matching is so rich and potentially
complex that it would be a brain-breaking task to assign an implicit
specificity to each and every match possibility. However, when you
think about it, the number of occasions when you say "match a div
descendant of the first chapter ancestor of the current node which
has an attribute type with a value intro" is rather small.

The majority of stylesheets will tend to say "match div elements" as
a default with maybe a special case for "match div within schedule".

This should be achievable by using something like:

   <xsl:template match="div">
   ...
   <xsl:template match="schedule/div">
   ...

without requiring explicit priority attributes. It is implicit that
the second template has a higher priority (since if the first was
higher, the second would never be applied at all).

I would suggest that the ordering be something like:

(0) Assemble all potential matches.

(1) Select the matches with the greatest number of "/" relations.

(2) Select the matches with the greatest number of "//" relations.

(3) Select the matches with the smallest number of "*" wildcards.

(4) Select the matches which include a test.

(5) Select the match with the higher priority.

The rules would be applied until only a single match remains. If
more than one match can be selected then an error would result and
priorities would have to be assigned. If a match includes
alternation, then the above rules would be applied to that
alternative which was actually used.

Yes, I know that theoretically this muddies the logic of rule
selection. But IN PRACTICE it could eliminate the need to assign
priorities in the vast majority of stylesheets. You will find that
people WILL want to use simple default/refinement stylesheet models
and that they will NOT in general want to be bothered with assigning
priorities when it's "perfectly obvious" what was intended.

The (default-priority) issue in section 2.5.1 of the spec is an
implicit recognition of this fact. I just want to go a little
further, so we can translate the stylesheet equivalents in our
current production systems into XSL without having to muck around
with priorities. Our stylesheeting does in fact allow explicit
priorities, but strangely enough we find we hardly ever want to use
them. By all means use priorities if you want to, but I don't think
that people should be forced to use them in situations where the
intent is clear.

Let me finish by stating that I realise that this issue must have
been discussed at length in the WG (and probably in the mailing list
as well - my study of the archives is still far from complete). If
there is a compelling reason to avoid all forms of specificity, let
me know and I'll shut up (or at least try to provide a more cogent
argument :)

Regards,
Geoff Nolan



================================
 Geoff Nolan - Turn-Key Systems
     Tel: +61 2 9906 1577
     Fax: +61 2 9906 1342
   Email: gjn@xxxxxxxxxxxxxx
================================


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


Current Thread