Subject: Re: [xsl] Grouping data at multiple levels (can XSL do this?) From: Senthilukvelaan <skumaravelan@xxxxxxxxxxxxxx> Date: Tue, 28 Jun 2011 18:33:38 -0700 |
Hi All, I have posted the similar question in the past. I am also trying to do something similar in xslt multi-level grouping based on the value of a node. <TAB_ITEM> <ZZBKITEM>TYPE1</ZZBKITEM> <QTY>1</QTY> <PRICE>99.00</PRICE> <EXT_PRICE>99.00</EXT_PRICE> <ZZBKSUBITEM/> </TAB_ITEM> <TAB_ITEM> <ZZBKITEM>TYPE1</ZZBKITEM> <QTY>1</QTY> <PRICE>99.00</PRICE> <EXT_PRICE>99.00</EXT_PRICE> <ZZBKSUBITEM/> </TAB_ITEM> <TAB_ITEM> <ZZBKITEM>TYPE2</ZZBKITEM> <QTY>1</QTY> <PRICE>99.00</PRICE> <EXT_PRICE>99.00</EXT_PRICE> <ZZBKSUBITEM/> </TAB_ITEM> Expected output: <TAB_ITEMS> <TAB_ITEM> <BKITEM>TYPE1</BKITEM> <QTY>1</QTY> <PRICE>99.00</PRICE> <EXT_PRICE>99.00</EXT_PRICE> </TAB_ITEM> <TAB_ITEM> <BKITEM>TYPE1</BKITEM> <QTY>1</QTY> <PRICE>99.00</PRICE> <EXT_PRICE>99.00</EXT_PRICE> </TAB_ITEM> <TAB_ITEMS> <OTHER_ITEMS> <TAB_ITEM> <BKITEM>TYPE2</BKITEM> <QTY>1</QTY> <PRICE>99.00</PRICE> <EXT_PRICE>99.00</EXT_PRICE> </TAB_ITEM> <OTHER_ITEMS> Please help me, how I do split into two different groups. Thanks Senthil On Tue, Jun 28, 2011 at 3:09 PM, Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> wrote: > Hi, > > To add to what David and Michael have said, in general there are three > families of solutions to problems of this sort in XSLT: > > 1. Sibling recursion: using recursive template calls to force a conditional > traversal; > 2. Key association: using keys to associate nodes into their proper groups > and subgroups; > 3. xsl:for-each-group, including using group-adjacent, group-starting-with > and group-ending-with. > > Method 3 is usually the most pleasant to conceive of and implement, > especially in case with multiple levels of nesting. But it requires XSLT > 2.0. This alone is a reason to use 2.0 if you have much of it to do, since > as Peter implies, the other methods can be hard. > > Pipelining and micropipelining can also be a help. > > So yes, XSLT can do it. > > Cheers, > Wendell > > On 6/28/2011 5:17 PM, Michael Kay wrote: >> >> You've described your problem in very procedural terms, so it's not >> surprising you are having trouble implementing it in a declarative >> language. Your readers including me will have the same problem - reverse >> engineering your requirements from an algorithm that doesn't work is not >> easy. >> >> If you show some sample input and output then we may be able to >> recognize how they are related. If the relationship isn't obvious, >> please try and explain it. Usually if you express the problem in terms >> of rules like "this element in the output depends on these things in the >> input" then an implementation in a functional language can be derived >> from this without much difficulty. >> >> Michael Kay >> Saxonica >> >> On 28/06/2011 19:47, Hank Ratzesberger wrote: >>> >>> Hello, >>> >>> I'm writing to this list for the first time because after using >>> XSL for some years I've come across a data pattern that I think >>> defies use by XSL. It is the kind of thing that a language that >>> allows you to alter/update variables and iterate through lists >>> can do with relative ease, but I don't find it possible with >>> XSL. It is an example of hierarchical meaning within flat >>> data, that is, there are groups of rows of data, but some >>> groups represent updates to information in prior groups. >>> >>> In pseudo code, something like this >>> >>> for each<receiver> >>> if (the<receiver> has a child<model-code>) then >>> create the element<myReceiverHistory> with all the children of >>> <receiver> >>> for each following-sibling of receiver that does not have a >>> <model-code> child >>> create a new<myReceiverHistory> by updating the most recent with >>> children info. >>> >>> It is the kind of thing that loop construct with variables that >>> can be updated within the loop or that has a "continue" to >>> skip to the next, etc. can do. >>> >>> Happy to be proved wrong or listen to your interest. >>> >>> I can pull rows out of a database and put them into an xml format. >>> They are tidbits that, when sorted by date, create a group of changes >>> that occur on permanent GPS site. So, starting from this: >>> >>> <result xmlns=""> >>> <row> >>> <site-transaction-type>frequency standard</site-transaction-type> >>> <site-transaction-name>type</site-transaction-name> >>> <site-transaction-value>INTERNAL</site-transaction-value> >>> <effective-date>1990-01-09T00:00:00.000</effective-date> >>> </row> >>> <row> >>> <site-transaction-type>frequency standard</site-transaction-type> >>> <site-transaction-name>additional information</site-transaction-name> >>> <site-transaction-value>ROGUE SNR-8 uses external rubidium >>> standard</site-transaction-value> >>> <effective-date>1990-01-09T00:00:00.000</effective-date> </row> >>> <row> >>> ...etc. etc. >>> >>> I can use for-each-group to >>> >>> <xsl:variable name="receivers"> >>> <xsl:for-each-group >>> select="$transactions/row[site-transaction-type='receiver']" >>> group-by="effective-date"> >>> <sopac:receiver xmlns:sopac="http://sopac.ucsd.edu/ns"> >>> <xsl:copy-of select="current-group()"/> >>> </sopac:receiver> >>> </xsl:for-each-group> >>> </xsl:variable> >>> >>> Which allows me to put all the things together that make up the actual >>> transaction. The catch is that only when one of the rows is a >>> "site-transaction-name" with the value 'model code' does it represent a >>> change to the receiver. Other changes, e.g. 'serial number' only >>> update the previous group of elements. The above creates this: >>> >>> <sopac:receiver xmlns:sopac="http://sopac.ucsd.edu/ns"> >>> <row xmlns=""> >>> <site-transaction-type>receiver</site-transaction-type> >>> <site-transaction-name>model code</site-transaction-name> >>> <site-transaction-value>TRIMBLE 4000SST</site-transaction-value> >>> <effective-date>1990-02-09T00:00:00.000</effective-date> >>> </row> >>> <row xmlns=""> >>> <site-transaction-type>receiver</site-transaction-type> >>> <site-transaction-name>firmware version</site-transaction-name> >>> <site-transaction-value>4.11</site-transaction-value> >>> <effective-date>1990-02-09T00:00:00.000</effective-date> >>> </row> >>> <row xmlns=""> >>> <site-transaction-type>receiver</site-transaction-type> >>> <site-transaction-name>serial number</site-transaction-name> >>> <site-transaction-value>496</site-transaction-value> >>> <effective-date>1990-02-09T00:00:00.000</effective-date> >>> </row> >>> <row xmlns=""> >>> <site-transaction-type>receiver</site-transaction-type> >>> <site-transaction-name>satellite system</site-transaction-name> >>> <site-transaction-value>GPS</site-transaction-value> >>> <effective-date>1990-02-09T00:00:00.000</effective-date> >>> </row> >>> <row xmlns=""> >>> <site-transaction-type>receiver</site-transaction-type> >>> <site-transaction-name>additional information</site-transaction-name> >>> <site-transaction-value>First measurements</site-transaction-value> >>> <effective-date>1990-02-09T00:00:00.000</effective-date> >>> </row> >>> </sopac:receiver> >>> <sopac:receiver xmlns:sopac="http://sopac.ucsd.edu/ns"> >>> <row xmlns=""> >>> <site-transaction-type>receiver</site-transaction-type> >>> <site-transaction-name>serial number</site-transaction-name> >>> <site-transaction-value>422</site-transaction-value> >>> <effective-date>1990-02-14T00:00:00.000</effective-date> >>> </row> >>> <row xmlns=""> >>> <site-transaction-type>receiver</site-transaction-type> >>> <site-transaction-name>sample interval</site-transaction-name> >>> <site-transaction-value>30</site-transaction-value> >>> <effective-date>1990-02-14T00:00:00.000</effective-date> >>> </row> >>> <row xmlns=""> >>> <site-transaction-type>receiver</site-transaction-type> >>> <site-transaction-name>additional information</site-transaction-name> >>> <site-transaction-value>Site ties 05-MAR-1990</site-transaction-value> >>> <effective-date>1990-02-14T00:00:00.000</effective-date> >>> </row> >>> </sopac:receiver> >>> >>> ... >>> >>> Even creating a variable with the necessary hierarchy is problematic >>> because I can't go back to get the data -- or maybe I can with >>> a tricky previous-sibling ? >>> >>> Thanks, >>> Hank >> >> > > -- > ====================================================================== > Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx > Mulberry Technologies, Inc. http://www.mulberrytech.com > 17 West Jefferson Street Direct Phone: 301/315-9635 > Suite 207 Phone: 301/315-9631 > Rockville, MD 20850 Fax: 301/315-8285 > ---------------------------------------------------------------------- > Mulberry Technologies: A Consultancy Specializing in SGML and XML > ======================================================================
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] How to pass an XPath as a, Hermann Stamm-Wilbra | Thread | Re: [xsl] Grouping data at multiple, Hank Ratzesberger |
[xsl] How to pass an XPath as a par, Richard Fozzard | Date | Re: [xsl] Grouping data at multiple, Hank Ratzesberger |
Month |