RE: [xsl] Integrated sort using different elements

["Michael Kay" <mike@xxxxxxxxxxxx>]

> Yup, it looks like the ones that don't sort right have empty 
> monogr/author. Unfortunately, I have to work with the TEI as 
> it is, as tempted as I am to tidy it up...

Two points:

(a) it really stresses the importance of showing us the input XML, rather
than merely describing it. In this case several of us were misled by your
description. Saying that a "field is present/absent" could mean anything,
because "field" has no meaning in XML, but several of us read it as meaning
the element is present/absent, not that the text node is present/absent.

(b) it's easy to adapt the solution. Instead of (A, B, C, D)[1], use
(A[normalize-space()], B[normalize-space()], C[normalize-space()],
D[normalize-space()])[1].

Michael Kay
http://www.saxonica.com/


> 
> ~Quinn
> 
> Michael Kay wrote:
> > When you talk of an element with no monogr/author, do you mean the 
> > monogr/author element is absent, or do you mean the element 
> is present 
> > and its value is empty? Being present but empty would 
> account for the 
> > results you are describing.
> >
> > Michael Kay
> > http://www.saxonica.com/
> >
> >   
> >> -----Original Message-----
> >> From: Quinn Dombrowski [mailto:qdombrow@xxxxxxxx]
> >> Sent: 19 February 2009 17:16
> >> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> >> Subject: Re: [xsl] Integrated sort using different elements
> >>
> >> Hi Ken,
> >>
> >> Thanks for the tip. A bit earlier, I tried the
> >>
> >> <xsl:sort select="
> >>  ( monogr/author, analytic/author, monogr/editor, monogr/title 
> >> )[1]"/>
> >>
> >> and it produced some kind of weird results. First it 
> listed the ones 
> >> with analytic/author but no monogr/author. Then the ones with a 
> >> monogr/title, and no author anywhere. Then it alphabetized all the 
> >> ones with monogr/author. (In my smaller test set, there 
> didn't happen 
> >> to be any editors.)
> >>
> >> I'm not sure what's happening there, but when I did:
> >>         <xsl:sort select="concat(monogr[1]/author[1],
> >> analytic[1]/author[1], monogr[1]/editor[1], monogr[1]/title[1])"/> 
> >> ([1]'s because there's sometimes multiple editions with multiple 
> >> authors)
> >>
> >> it sorted everything the way I needed it. I'm not sure if the data 
> >> happens to be such that the concat() problem you mentioned doesn't 
> >> come up, but one way or another it works.
> >>
> >> Thanks everyone for your help! This has really been a life saver.
> >>
> >> ~Quinn
> >>
> >>
> >> G. Ken Holman wrote:
> >>     
> >>> At 2009-02-19 10:13 -0600, Quinn Dombrowski wrote:
> >>>       
> >>>> I'm using 2.0 (sorry, I should've mentioned that), so I'll try 
> >>>> Michael's solution and let you know how it goes...
> >>>>         
> >>> Before you do so, Quinn .....
> >>>
> >>> At 2009-02-19 10:19 -0500, I wrote:
> >>>       
> >>>> In XSLT 2.0, choose the first item in a sequence of many items, 
> >>>> priority indicated by the order of your sequence:
> >>>>
> >>>> <xsl:sort select="
> >>>>  ( monogr/author, analytic/author, monogr/editor, monogr/title 
> >>>> )[1]"/>
> >>>>         
> >>> At 2009-02-19 15:47 +0000, Michael Kay wrote:
> >>>       
> >>>> Would it work to sort on the concatenation? -
> >>>>
> >>>> <xsl:sort select="concat(monogr/author, analytic/author, 
> >>>> monogr/editor, monogr/title"/>
> >>>>         
> >>> I think the sequence solution is safer than the
> >>>       
> >> concatenation solution
> >>     
> >>> because if more than one field is present, then the initial
> >>>       
> >> characters
> >>     
> >>> of a following field, tacked on to the final characters of
> >>>       
> >> a preceding
> >>     
> >>> field, will but the record out of order.
> >>>
> >>> Consider the following:
> >>>
> >>> <biblStruct id="b1">
> >>>   <monogr>
> >>>     <author>abc</author>
> >>>     ...
> >>>   <analytic>
> >>>     <author>xyz</author>
> >>>   ...
> >>> <biblStruct id="b2">
> >>>   <monogr>
> >>>     <author>abcdef</author>
> >>>
> >>> Using the sequence approach would put "b1" before "b2" in
> >>>       
> >> the result
> >>     
> >>> because "abc" is before "abcdef", while using the concatenation 
> >>> approach would put "b2" before "b1" in the result because
> >>>       
> >> "abcdef" is
> >>     
> >>> before "abcxyz".
> >>>
> >>> I hope this illustrates an important issue that was
> >>>       
> >> neglected in your
> >>     
> >>> decision.
> >>>
> >>> . . . . . . . . . . Ken
> >>>
> >>> --
> >>> Upcoming hands-on  XQuery, XSLT, UBL & code list training classes:
> >>> Brussels, BE 2009-03;  Prague, CZ 2009-03, 
> http://www.xmlprague.cz 
> >>> Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
> >>> Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
> >>> Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
> >>> G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
> >>> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
> >>> Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/s/bc
> >>> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal