RE: [xsl] Unions and/or temporally related groups

[Tony Click <Tony.Click@xxxxxxxxx>]

Yup I forgot to mention that.  A time element can contain 0 to many data
elements and within a time element data elements are unique based on channel
(i.e. there will be no cases of channel 1 with more than one parameterSet).

Under normal circumstances a time element will have 2 to 4 channels (80% of
the time), there are some reports where there may be 10-20 channels, and
rarely, but occcasionally there may be hundereds of channels.  The physical
limit is 50,000 channels.

I explored the option of concatenating the two strings.  Like you said, I
think I can make it work by using a unique separator (something like ":"
won't occur in the real data), and that may be the choice I make, for some
reason that makes me feel icky - thats why I'm looking for another option.

The xpath extension operator idea is good - I just don't know if I can do
that.  I've sort of got an unwritten but highly emphasised requirement to be
able to plug various xslt processors without changes.  Currently we have to
work with Xalan and microsoft's processor.

Thanks again.

-Tony

-----Original Message-----
From: tcn@xxxxxxxxxxxxx [mailto:tcn@xxxxxxxxxxxxx]
Sent: Friday, July 13, 2001 6:11 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] Unions and/or temporally related groups


Hi Tony,

You missed out a vital bit of the spec: can a given time element
contain more than one <data/> for the same value of channel and
parameterSet?  For what follows I am assuming not.  How many elements
might a given <time/> contain?

You are right that the union operator is picky regarding what counts
as the 'same' node - it has to be the same node from the original
document, even an xsl:copy-of won't do.  As well as working with
values, you seem to want to ignore the 'value' attribute I think?

I think you are also right to throw out 'key' if you can do it on the
basis of this node and the next, at least for a key working in the
context of the whole input file.

In terms of node sets you are looking for something like the
following.  The current context is a time element, and $next is its
following-sibling.  I abbreviate your attribute names to the first
letter so we see the wood rather than the trees.

    name[$next/name[@c=^@c and @p=^@p]]

where ^ is an XPath operator I just invented meaning 'context of the
context'.  A sort of ./.  There is no such animal as far as I know,
but maybe someone else does - extension function anyone?  Besides,
this involves a pairwise comparison of each node so the performance
characteristic is bad news if you have lots of elements within each
time.

Can you do a transformation on a given time element to produce a
string characteristic of the c and p values present?  Something like

  <xsl:variable name="this-id">
    <xsl:for-each select="data">
          <xsl:sort select="@c" />
          <xsl:sort select="@p" />
          <xsl:value-of select="concat(@c,@p)"/>
   </xsl:for-each>
  </xsl:variable>

You may be able to discard the sort, and you may need to put some
separators in so as not to confuse @c='1' @p='11' with @c='11' @p='1'.
Do likewise for $next/data and then the problem boils down to
comparing two strings.

Of course you end up calculating the 'characteristic' of each time
element twice.  Might be worth considering doing it in two passes, but
I doubt it unless you do it as some sort of SAX filter.

Does this help?

Regards,
Trevor Nash
--
Traditional training & distance learning,
Consultancy by email

Melvaig Software Engineering Limited
voice:     +44 (0) 1445 771 271 
email:     tcn@xxxxxxxxxxxxx

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list