Subject: RE: [xsl] Detecting a break in data From: "Smith, Graham" <Graham.Smith@xxxxxxxxxx> Date: Wed, 19 Jun 2002 12:17:11 -0400 |
Good Grief! Someone else that uses Mercator...? You're absolutely right. Is there a Mercator process built in? If so, we should take this off-line to discuss further... However, I want to know how to do it with XML/XSL ayway. Thanks Jan, Graham. -----Original Message----- From: Hesselberth, Jan [mailto:Jan.Hesselberth@xxxxxxxxxxxxxxxxxx] Sent: 19 June 2002 16:28 To: 'xsl-list@xxxxxxxxxxxxxxxxxxxxxx' Subject: RE: [xsl] Detecting a break in data I know this may not be the place to send this but the xml looks like a Mercator map. If so it may be easier to define (or use the Mercator supplied) Type Tree for the xml and use a Mercator map to format the required output. Cheers Jan -----Original Message----- From: TSchutzerWeissmann@xxxxxxxxxxxxxxxx [mailto:TSchutzerWeissmann@xxxxxxxxxxxxxxxx] Sent: 19 June 2002 16:15 To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx Subject: RE: [xsl] Detecting a break in data Graham, ... > ...and I want to display this as... > > Rule 1: RecordTy (Key_Data in Type_01) = "1" > Rule 2: RemitID (Key_Data in Type_01) = NONE > Rule 3: CompNum (Key_Data in Type_01) = NONE > Rule 4: Sequence (Key_Data in Type_01) = Index > --- > Rule 5: Vmhkey (Rec01 in Type_01) = SPXVDR SP_Field:In1 > Rule 6: Activsw1 (Rec01 in Type_01) = IF( SPSUST > SP_Field:In1=" ","N","Y" ) > . > . > . > Rule 60: Vmorigin (Rec01 in Type_01) = NONE > > --- > > Rule 61: VendorID (Key_Data in Type_02) = SPXVDR SP_Field:In1 > Rule 62: RecordTy (Key_Data in Type_02) = "2" > Rule 63: RemitID (Key_Data in Type_02) = SPXRMT SP_Field:In1 > Rule 64: CompNum (Key_Data in Type_02) = NONE > Rule 65: Sequence (Key_Data in Type_02) = Index > --- > Rule 66: Vrvendid (Rec02 in Type_02) = SPXVDR SP_Field:In1 > Rule 67: Vrremid (Rec02 in Type_02) = SPXRMT SP_Field:In1 > > The form of the actual XML is... > > <MapRule rulenumber="4"> > <objectset>Sequence Key_Data Field:Type_01 > Record:Out</objectset> > <objectrule>=Index</objectrule> > </MapRule> > <MapRule rulenumber="5"> > <objectset>Vmhkey Rec01 Field:Type_01 Record:Out</objectset> > <objectrule>=SPXVDR SP_Field:In1</objectrule> > </MapRule> > So: you're grouping MapRule nodes according to the stuff in parantheses, eg "(Rec02 in Type_02)", which is a smaller part of the string value of the objectset child node. Grouping is xslt uses keys, which are a quick way of getting at nodes using a lookup. You declare a key outside any template: <xsl:key name='byObjectSet' match="MapRule" use="objectset"/> You access nodes according to a particular value of the use expression, eg ... key('byObjectSet','"Vmhkey Rec01 Field:Type_01 Record:Out"') will give you all the MapRule nodes with an objectset child whose value is "Vmhkey Rec01 Field:Type_01 Record:Out". Which is all very well, in that it will give you a group, but you won't want to hardcode the lookup value in this way. On the other hand, if you could get a list of distinct values for objectset, then you could get a group of nodes for each distinct value, exactly what you need. The Muenchian method does this as follows: <xsl:for-each select="MapRule [generate-id(.) = generate-id( key('byObjectSet', objectset)[1])]"> The lookup value for the key is the objectset child of the MapRule node. That node only gets through if it's identical to the first node of the group returned by the key, and this will only be true once for every distinct value of the objectset node. Then you can begin your group and output its members: <group> <xsl:for-each select="key('byObjectSet',objectset)"> <xsl:copy-of select="."/> </xsl:for-each> </group> In your case you will have to refine it a bit because you're only interested in a section of the objectset value, not all of it. Maybe you can hack at it with substring-before and substring-after, so instead of objectset plain and simple, use substring-after(substring-before(objectset, ' Record:'),' ') in your key. This is ugly and unreliable because I don't know enough about your incoming data. In fact, it's plain ugly anyway. You could massage the data into more tractable form with a preliminary stylesheet, maybe? have a look at http://www.jenitennison.com/xslt/grouping/ for a much better explanation... Cheers, Tom XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list -------------------------------------------------------------------------- CONFIDENTIALITY The information contained in this e-mail and any files transmitted with it is private and confidential. It is intended for the named addressee only. If you are not the intended addressee you are prohibited from storing, copying or using the information in any way. If you received this e-mail due to a transmission error please notify the sender immediately. No liability is accepted by Northern Rock for any losses caused by viruses contracted during transit over the Internet or present in any receiving system. This e-mail is not intended to create legally binding commitments on behalf of Northern Rock plc, nor do its contents reflect the corporate views or policies of Northern Rock plc. -------------------------------------------------------------------------- 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Detecting a break in data, Hesselberth, Jan | Thread | RE: [xsl] Detecting a break in data, Smith, Graham |
RE: [xsl] Hello World, Jeff Beadle | Date | Re: [xsl] Hello World, David Carlisle |
Month |