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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Processing Modes..., Geoff Nolan | Thread | Standard API to XSL processors, Oren Ben-Kiki |
Re: Feature Request - Node Set Proc, James Clark | Date | Complex Sorting, Geoff Nolan |
Month |