I thought some more about it, and the current situation is a bit of a can of   
worms, I'd say. Consider the following expression:   
   
xs:duration(xdt:dayTimeDuration("P365D"))   
       eq   
xs:duration(xdt:yearMonthDuration("P1Y"))   
   
   
From what I can tell, the validity of this expression depends on whether the   
dynamic types(xdt:dayTimeDuration/xdt:yearMonthDuration) or the static   
types(xs:duration/xs:duration) are used for the operator lookup. Perhaps,  
behavior could in practice become implementation dependent, considering the  
freedom implementations have in handling the types of values(subtype  
substitution, for example). The essence seems to be that in the case of the  
duration operators one can't rely on the very primitive base type(which  
one can in all other cases), but that a sub-type/dynamic type might be of  
importance. But yes, the solution Michael proposed seems to solve all this.  
  
Also, the pseudo function in op:duration-equal can be simplified into:   
   
return cast as xdt:yearMonthDuration($arg1) eq   
       cast as xdt:yearMonthDuration($arg2)    
                and   
       cast as xdt:dayTimeDuration($arg1) eq    
       cast as xdt:dayTimeDuration($arg2)  
  
It is less code(the if-expression was removed), but, of course, that doesn't  
necessarily mean readability is improved.  
   
  
Frans   
   
  
  

In the expression

xs:duration(xdt:dayTimeDuration("P365D"))   
       eq   
xs:duration(xdt:yearMonthDuration("P1Y"))   

both the static and dynamic type of the two values will be xs:duration (the 
cast changes the dynamic type as well). So I do not see your problem....

     
Yes Rys, I think you are right.    
    
I don't know your reasoning, but from what I can tell a cast expression can    
return a value whose type is more specific than the static one(from the 
definition of dynamic type). However, the reason why that doesn't apply to this 
particular case of xs:duration/xdt:dayTimeDuration is that the relevant 
sections in F&O special case those; xdt:dayTimeDuration isn't treated as a 
xs:duration value.    
    
Curiosity: my conclusion is that the expression in comment #1 triggers a   
bug in Saxon, but when Saxon implements what likely is the result of this   
report(the eq ops for xdt:durations are removed) the bug will go away.   
    
    
Frans   
   
     

The Saxon problem is off-topic for this list, but is now fixed.

Michael Kay

"I don't know your reasoning, but from what I can tell a cast expression can 
return a value whose type is more specific than the static one(from the 
definition of dynamic type)."

Sorry, but a cast cannot return a more specific dynamic type than the static 
type. Casting is actually changing the dynamic type and transforms the value 
from one type's value space to another type's value space.

"treat as" does not change the dynamic type...

In discussion it emerged (i.e., Mary Holstege noticed!) that we can't simply get
rid of op:yearMonthDuration-equal and op:dayTimeDuration-equal because the
definition of op:duration-equal invokes these functions implicitly. On the other
hand, the definition of equality on the two subtypes is not saying anything very
profound. So we probably need a revised definition of op:duration-equal, in
which case the other two functions can be dropped. I was actioned to write a
concrete proposal.

"Sorry, but a cast cannot return a more specific dynamic type than the static 
type."

I've asked myself this question a number of times, and have come to the
conclusion that the result of a cast *can* be a subtype of the type requested. I
think it is a general property of our processing model (see 2.2.3.2) that
expressions can return a value whose dynamic type is a subtype of the type
implied by the static signature. For example the specification requires that the
result of 1+1 is an xs:integer, and an implementation that returns a value of
type xs:short conforms to this requirement because every xs:short is an
xs:integer. By the same reasoning it is acceptable for xs:int(1+1) to return a
value whose most specific type is xs:short. 

In Saxon, casting to a supertype is generally a no-op, and I believe this is
conformant.

I agree with your interpretation for arithmetic. But this is incorrect when 
casting. Casting per definition needs to change both the static and dynamic 
type. Casting up the type hierarchy is only a noop regarding the value 
transformation, but it has to change the type annotation...

Best regards
Michael

Note that 365D is not necessarilly equal to 1Y. Isn't this why we have two
distinct, non-overlapping sub-types of xs:duration in the first place?

The discussion on this bug has explored some interesting side alleys, but I'm
now trying to fulfil action A-288-29 by proposing changes for how durations
should be compared for equality (that is, eq and ne).

1. In the XPath/XQuery book, appendix B.2, delete the lines

A eq B 	xdt:yearMonthDuration 	xdt:yearMonthDuration 	
A eq B 	xdt:dayTimeDuration 	xdt:dayTimeDuration 
A ne B 	xdt:yearMonthDuration 	xdt:yearMonthDuration 	
A ne B 	xdt:dayTimeDuration 	xdt:dayTimeDuration	

2. In F+O delete sections 10.4.1 (op:yearMonthDuration-equal) and 10.4.4
(op:dayTimeDuration-equal)

3. To 10.4.7 op:duration-equal add after the second paragraph:

Note that this function (like any other) may be applied to arguments that are
derived from the types given in the function signature, including the two
subtypes xdt:dayTimeDuration and xdt:yearMonthDuration. With the exception of
the zero-length duration, no instance of xdt:dayTimeDuration will ever be equal
to an instance of xdt:yearMonthDuration.

Change the definition of the semantics of the function to read:

The semantics of the function are defined by the following expression:

xdt:yearMonthDuration($arg1) div xdt:yearMonthDuration('P1M')
 eq
xdt:yearMonthDuration($arg2) div xdt:yearMonthDuration('P1M')
    and
xdt:dayTimeDuration($arg1) div xdt:dayTimeDuration('PT1S')
 eq
xdt:dayTimeDuration($arg2) div xdt:dayTimeDuration('PT1S')

that is, the months and seconds components of the two durations are each equal.
 

To the examples, add

op:duration-equal(xdt:yearMonthDuration('P0Y'), xdt:dayTimeDuration('PT0D'))
returns true

op:duration-equal(xdt:yearMonthDuration('P1Y'), xdt:dayTimeDuration('PT365D'))
returns false

A minor addition to the proposal in comment #10:

Take the existing examples in sections 10.4.1 (op:yearMonthDuration-equal) and
10.4.4 (op:dayTimeDuration-equal) and add them to the revised section 10.4.7
op:duration-equal.

Michael Kay

Ignore comment #11. There are no existing examples in sections 10.4.1
(op:yearMonthDuration-equal) and 10.4.4 (op:dayTimeDuration-equal). Instead,
create some new examples:

op:duration-equal(xdt:yearMonthDuration('P2Y'), xdt:yearMonthDuration('P24M'))
returns true

op:duration-equal(xdt:dayTimeDuration('P10D'), xdt:dayTimeDuration('PT240H'))
returns true

op:duration-equal(xs:duration('P2Y0M0DT0H0M0S'), xdt:yearMonthDuration('P24M'))
returns true

op:duration-equal(xs:duration('P0Y0M10D'), xdt:dayTimeDuration('PT240H'))
returns true

Michael Kay
 

We accepted the solution in comment #10 and #12.