Re: Side-effects, state, internal references

Subject: Re: Side-effects, state, internal references
From: Paul Prescod <papresco@xxxxxxxxxxxxxxxx>
Date: Thu, 16 Apr 1998 20:29:15 -0400
Jonathan Marsh wrote:
> 
> The functions
> available (e.g. childNumber) count relative to the SOURCE element, not to
> the output elements.

<NIT>XSL does not output elements. XSL outputs flow objects.</NIT>

> This is a symptom of a general problem with XSL right now.  

This may or may not be a problem, but either way, it is not an
oversight. My understanding is that this restriction of DSSSL is quite
conscious, and I have argued (ad nauseum) that CSS should not abandon
this model by allowing "counters" based on output objects. The reason
DSSSL does not number output flow objects is because that would mean
that to render flow object 1,000,000 you must execute the construction
rule for every flow object that precedes it. That's nasty in a WYSIWYG
editor. Whereas if you build a "numbering query" then flow object
1,000,000 can be rendered as quickly (or as slowly) as the query can be
executed. There are a large number of optimizations that can be applied
to a query that cannot be applied to arbitrary construction rules.

Anyhow, if I understand the original question, it is very easy solved in
DSSSL and thus in the "DSSSL model". Here's how I would transliterate it
into ECMAScript: 

elementNumberList( ["HEAD", "PROD"], currentNode() )[2]

That's it. The problem you asked about is a little more tricky, because
it essentially uses attributes as element types:

> Or alternatively how would you do this correctly?  Given
> <A>
>         <B level="1">first level 1 B</B>
>         <B level="2">first level 2 B</B>
>         <B level="1">second level 1 B</B>
>         <B level="1">third level 1 B</B>
>         <B level="2">second level 2 B</B>
> </A>
> 

Both DSSSL and XSL are heavily weighted to make querying on element
types really easy. Querying on attributes is harder. I don't think that
the case above happens often enough to be worth making such a
fundamental change to XSL. It would be better to just improve the
elementNumberList procedure:

elementNumberList( ["A", "B level='1'"], currentNode() )[2]

This is of course a made-up syntax, but you should be able to get the
picture. There may be an easy way to do this in DSSSL as it stands, but
I can't think of it off of the top of my head. I guess the best I can do
off the top of my head is to flatten the nodelist with ipreced, query
for the start of the last "A" and then count the matching "B"s. This is
a hassle, but I really don't think it happens very often in real
documents.

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

"I want to give beauty pageants the respectability they deserve."
            - Brooke Ross, Miss Canada International


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


Current Thread