Re: [xsl] Grouping data at multiple levels (can XSL do this?)

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