RE: Side-effects, state, internal references

Subject: RE: Side-effects, state, internal references
From: Jonathan Marsh <jmarsh@xxxxxxxxxxxxx>
Date: Thu, 16 Apr 1998 09:49:57 -0700
> -----Original Message-----
> From: Michel Goossens [mailto:Michel.Goossens@xxxxxxx]
> Sent: Thursday, April 16, 1998 8:00 AM
> The general structure is:
> 
> <scrap>
> <head>
> <prod><lhs><rhs>.....</prod>
> </scrap>
> <scrap>
> <head>
> <prod><lhs><rhs>..<rhs>...</prod>
> </scrap>
> <scrap>
> <head>
> <prodgroup>
> <prod><lhs><rhs>.....</prod>
> <prod><lhs><rhs>.....</prod>
> <prod><lhs><rhs>.....</prod>
> </scrap>
> 
> And I would like to get:
> 
> Header 1
> (1) Production Rule 1
> (2) Production Rule 2
> ..
> 
> Where the number between brackets is generated automatically.

This is a symptom of a general problem with XSL right now.  The functions
available (e.g. childNumber) count relative to the SOURCE element, not to
the output elements.

Another example of this problem would be a rule that produced numbered
output for your <scrap> elements while filtering out or reordering some of
them.  For instance, if some criteria filtered out the second <scrap>,
childNumber would still give "1,3" instead of "1,2".  Likewise, if my XSL
reordered <scraps> in reverse, the numbers would still be "3,2,1".  Not very
useful.

One solution might be to build counting behavior directly into the flow
objects, such as the HTML <OL> provides.  A more general solution would be
for XSL to provide counting functions relative to the output tree, e.g.
flowObjectChildNumber().

> A second more tricky problem is that several production rules
> refer to each other...
> 
This also is a deficiency in XSL, it is hard to follow references.  Adding
an ID/IDREF navigation capability within the query (<select-elements>) might
provide an adequate basis for a solution.

Jonathan Marsh


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


Current Thread