According to section 17.1.2 "Casting to xs:string and xdt:untypedAtomic" of the 
F&O spec, if a datatype is not listed in this section, and it does not have a 
canonical representation defined in Schema (which is the case for xs:duration), 
then an "implementation dependent canonical representation may be used".  

According to schema 1.0, "The value space of duration is a six-dimensional 
space"
According to schema 1.1, "Durations can be modeled in at least two ways: as six-
property tuples (...) or as two-property tuples" 

For example:  cast xs:duration('P1Y13M40DT1H 61M1S') to xs:string
An implementation would likely produce one of the following results:

1. six-property model = P1Y13M40DT1H 61M1S  (no change)
2. two-property model = P25MT3463261S (months and seconds)
3. normalize based on xdt:yearMonthDuration and xdt:dayTimeDuration = 
P2Y1M40DT2H1M1S

Since xs:duration is a built-in type and casting to string is a common 
operation, casting from xs:duration to xs:string or xdt:untypedAtomic should 
not be implementation dependent.

Suggested Resolution:  3. normalize based on xdt:yearMonthDuration and 
xdt:dayTimeDuration

New bullet in section 17.1.2 Casting to xs:string and xdt:untypedAtomic

If ST is xs:duration, then let SYM be SV cast as xdt:yearMonthDuration, and let 
SDT be SV cast as xdt:dayTimeDuration;  Then the next intermediate value, TYM, 
be SYM cast as TT, and let TDT be SDT cast as TT.  If TYM is "P0M", then TV is 
TDT.  Otherwise, TYM and TDT are merged according to the following rules:
	1.  If TDT is "PT0S", then TV is TYM
	2.  Otherwise, TV is the concatenation of all characters in TYM and all 
characters except the first "P" and the optional negative sign in TDT.


Joanne
[on behalf of XTTF]