[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] xsl:number problem


Subject: RE: [xsl] xsl:number problem
From: "Yan, Charlene" <Charlene.Yan@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 20 Jun 2003 17:10:50 -0400

Wendell,

Please see my comments after the separator
===========

-----Original Message-----
From: Wendell Piez [mailto:wapiez@xxxxxxxxxxxxxxxx]
Sent: Friday, June 20, 2003 3:34 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] xsl:number problem


Hi Charlene,

At 01:54 PM 6/20/2003, you wrote:
>I'm not sure you understand what xsl:number is doing. Could you paraphrase
>it for me? If you're not absolutely sure about it, it's something to look
>up. (Many resources are available, including Google.)
>
><xsl:template match="productId">
> >      <gmr:Cell Col="0" ValueType="60">
> >       <xsl:variable name="rownumber"><xsl:number level="any"
> > count="productId"/></xsl:variable>
> >       <xsl:attribute name="Row">
> >          <xsl:value-of select="$rownumber"/>
> >       </xsl:attribute>
> >        <gmr:Content>
> >                 <xsl:apply-templates/>
> >         </gmr:Content>
> >      </gmr:Cell>
> >   </xsl:template>
>===================================================================
>Here xsl:number is counting all the productId in the tree.

Nope, bzzt. Fraid not. xsl:number returns a string whose value depends on 
the location of the context node. (As specified in the XSLT Rec. The value 
is calculated based on a set of parameters provided as attributes on the 
instruction. In this case, the value will be based on the position of the 
context node relative to the set of productId nodes in the document.) (Q2: 
what is the context node here?)
===================================================
The context node is product.  I totally agree with your explanation above.  I said it wrong.


>   Having or not having "//" in front of productId is not making a 
> difference because I start from the root node here.

You only happen to be correct on this one. whether you are starting from 
the root is not relevant since the expression is evaluated as a pattern (as 
Mike K. just pointed out). So you are correct: it makes no difference here, 
but not for the reason you appear to be thinking.

>   The result of <xsl:number/> is the value of variable $rownumber.  It is 
> set as the value of attribute Row.  <xsl:apply-templates/> will put the 
> actual productId's node value into the cell.  It is doing a loop 
> here.  The results is
>1 ==> in Cell 1
>2 ==> in Cell 2
>3 ==> in Cell 3
>4 ==> in Cell 4
>5 ==> in Cell 5

I submit that it appears to be doing a loop, since in your view it is 
stepping one at a time through the elements in the source document. Would 
you be surprised if I told you that it might not actually be "looping" in 
order to achieve this effect? XSLT defines that the order of the output, 
unless you sort the input node set, shall be as if the nodes were processed 
in "document order" in the input. It does not, however, say that there is 
or must be a "loop" here.

(I couldn't say whether your XSLT processor -- Xalan? -- is looping. And 
that's exactly the beauty of it: I can help with your XSLT without 
worrying, as long as I know the processor is doing it's job. :-) It's like 
the difference between telling the guy who's painting your house, "paint 
this room first", and telling him "okay, dip the brush in the paint like 
this, and stroke it vertically on this wall over here, up and down, about 
this thick" and so forth. Which painter would you rather have, the one who 
already knows how to paint, right? Same thing: we don't have to tell an 
XSLT processor to loop: it already knows, mostly, when and where it may 
need to do this.)

>I use xsl:number here becuase it worked perfectly based on my old 
>requirements.

It makes sense. Now you are stuck because although you know it *did* work, 
you don't know *why*. Which is why you need to study the processing model. 
(And take a look at that raw output.)

>   I use count(//productId) in some other places to get the total number 
> productIds in the tree.  However, client is requiring that only NETg and 
> Wave products should be displayed.  That is why I need to add 
> publisher='NETg'...  I did do some reading on xPath already...  Anyway, 
> it seems that count="productId[publisher='NETg' or publisher='Wave']" is 
> not doing what I want.  I just have to dig in more.

Yes, I concur: but concentrate for a little on the XSLT side of the house. 
The reason XPath is hard to learn is because it's often approached out of 
context. Understand what XSLT is doing with it (including such arcane 
points as the difference between an XPath select expression and a match 
pattern), and XPath isn't like trying to hold a candle in a dark room. 
Instead, the lights are on.

>if I use xml serializer to transform it.  It ooutputs the exact xml I put 
>in.  It helps if you can try it in Cocoon.  I am using Cocoon 2.1M2.  If 
>you go to http://localhost:8080/cocoon/samples/stream/order and paste my 
>xml in there.  Submit it will get to the serialized xml.  If you change 
>the transform xsl in the sitemap under stream to my xsl, you will see the 
>exact output.

Yes, you see, this is exactly the problem. I can get the XML if I duplicate 
your processing environment. I could also just run your source with your 
stylesheet in the XSLT processor of my choice, and see what I get -- start 
the debugging from there. But then I'd be trying to do your job, wouldn't 
I? Without knowing anything about your requirements except what you're able 
to tell me in email?

>Well, it is kind of hard to use different tools (xslt, poi, Cocoon 
>StreamGenerator) and explain them clearly.

Isn't it? Cocoon, Excel, Saxon, MSXML, the more the crazier. That's why we 
keep discussion on the list focused on the stuff they have in common (the 
XSL technology standard as specified in the relevant W3 Recs) rather than 
getting into details of the different tools (for which you should be 
provided with other resources in any case). If one or another tool fails to 
conform in some way, we like to hear about it (just so we know -- and it's 
amazing what a collective memory can retain); otherwise there's enough work 
to do just with XSLT.

And also why we often, as developers, take care not to become too dependent 
on our tools, but rather become familiar with the specs they claim 
conformance to and how well they actually manage to conform.

Q3: What is the relation between the XPath data model and the XSLT 
processing model? (60 words or less.)
========================================
I have to do some research before I can give you a satisfactory answer ==>  satisfactory is based on my standard. ==>  Your standard is much higher than mine.:)


>THANKS for your help.

You are welcome.

======================================
I really appreciate your thorough explanation!!!  I'm learning a lot from this list and hoping to get better and be able to help others too.

Have a nice weekend!

Regards,
Charlene

>PS:  I did do a lot of homework before I ask the question.:))

You're getting 100% for effort so far. You just have a lot of studying and 
practice to do before you can work the switches and get the problem fully 
illuminated.
===============================
Thank you for your recognition!  Feeling good finally.:)

Have fun :->

Wendell


___&&__&_&___&_&__&&&__&_&__&__&&____&&_&___&__&_&&_____&__&__&&_____&_&&_
     "Thus I make my own use of the telegraph, without consulting
      the directors, like the sparrows, which I perceive use it
      extensively for a perch." -- Thoreau


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


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



Current Thread
Keywords