[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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
miss canada brooke ross
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.