This will almost certainly be easier in XSLT 2.0 than in 1.0. Would you be
content with a 2.0 solution? 

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

> -----Original Message-----
> From: David J Birnbaum [mailto:djbpitt+xml@xxxxxxxx] 
> Sent: 15 May 2007 14:49
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject:  if a condition is not met
> 
> Dear xsl-list,
> 
> I've run into a blind spot with an XSLT problem, and I was 
> wondering whether someone might be able to advise. Here's the problem:
> 
> I have a set of times and set of people scheduled at 
> different time ranges, e.g.:
> 
>    <times>
>        <time time="t1100">11:00</time>
>        <time time="t1130">11:30</time>
>        <time time="t1200">12:00</time>
>        <time time="t1230">12:30</time>
>        <time time="t0100">1:00</time>
>        <time time="t0130">1:30</time>
>        <time time="t0200">2:00</time>
>        <time time="t0230">2:30</time>
>        <time time="t0300">3:00</time>
>        <time time="t0330">3:30</time>
>        <time time="t0400">4:00</time>
>        <time time="t0430">4:30</time>
>        <time time="t0500">5:00</time>
>    </times>
>    <cells>
>        <cell startTime="t1100" endTime="t0100">Marquette</cell>
>        <cell startTime="t0200" endTime="t0300">Birnbaum</cell>
>        <cell startTime="t0300" endTime="t0400">Konsko</cell>
>        <cell startTime="t0400" endTime="t0500">Frasier</cell>
>    </cells>
> 
> The <time> elements denote half-hour blocks, with only the 
> beginning specified in a "time" attribute (since the end is 
> predictable by grabbing the "time" attribute of the 
> immediately following sibling; there isn't a real 5:00 block, 
> and that element exists only because it defines the end of 
> the 4:30 block). The <cell> elements indicate who works at 
> which time, with the time spans expressed in human terms. In 
> other words, that Marquette works from t1100-t0100 (in the attribute
> values) means that she works in the 11:00-11:30, 11:30-12:00, 
> 12:00-12:30, and 12:30-1:00 time blocks (but not the 
> 1:00-1:30 one). One rule for this schedule is that no time 
> assignments can overlap, so if (for example) Marquette is 
> scheduled between 11:00 and 1:00, I can be confident that 
> nobody else will be scheduled then.
> 
> I need to walk through the list of times and determine for 
> each one whether someone is scheduled then or not. I can do 
> an <xsl:for-each> over the time elements to examine each one 
> in turn, of course, but I can't seem to figure out an elegant 
> strategy for determining which are
> *not* busy (determining which are busy is easier; see below). 
> I need to treat start times differently fom spanned times 
> (that is, if someone works from 11:00-1:00,
> 
> I need to do one thing with the 11:00 slot and something 
> different with the 11:30, 12:00, and 12:30 slots) The start 
> times for the four cells in the example above (11:00, 2:00, 
> 3:00, and 4:00) are easy because I can save the value of the 
> "time" attribute (as something like variable
> "$inWhichTime") on each pass through the <time> loop and do an:
> 
> <xsl:for-each select="cell">
>    <xsl:if test="./@startTime=$inWhichTime">
>       <!-- yes, a scheduling event starts at this time, so 
> the time is occupied -->
>    </xsl:if>
> </xsl:for-each>
> 
> The problem them, is with the spanned times, the ones that 
> occur within but do not start an event. How do I find out 
> whether no scheduling event is going on at 11:30 (for 
> example)? I need to generate a result (but only one result) 
> if the time is *not* scheduled, so I can't just loop over the 
> four cells, because if I do that I'll find that nothing is 
> going on during three of them and I'll generate three 
> results, instead of the one I need. What I want to do in 
> pseudo-code is:
> 
> for each time element
>    is there a cell that occurs during (but does not begin) that time?
>       if any cell meets that condition, do nothing at all 
> within that pass through the time loop
>       if no cell meets that condition, do something, but do 
> it only once
> (total) during that pass through the time loop
> 
> My intuition tells me that I may not be seeing the solution 
> because I've conceptualized the problem badly, but I've been 
> banging on it for a couple of days now and it isn't getting 
> any clearer. Any insights would be welcome!
> 
> Thanks,
> 
> David
> djbpitt+xml@xxxxxxxx