RE: xsl:number problem
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.)
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?)
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
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.)
THANKS for your help.
You are welcome.
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.
Have fun :->
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format