The issue is simple and well known. The primitive datatype "xs:duration" which follows the format "PnYnMnDTnHnMnS" lets us mix durations expressed as years and months and durations expressed as days, hours, minutes and seconds.

The number of days in a month (between 28 and 31) and in a year (between 365 and 366) being variable, the order between duration mixing all these units is only partial. For instance, the result of the comparison between the two durations "P1M" (1 month) and "P30D" (30 days) is undetermined since a month can be either 28, 29, 30 or 31 days.

For applications which need duration with a total order relation, the workaround is well known: we define subtypes for durations expressed either as months and years or as seconds, minutes, hours and days.

These subtypes may be defined by derivation by restriction using the xs:pattern facet (see for instance the corresponding section of my book "RELAX NG"):

  <define name="YMduration">
    <data type="duration">
      <param name="pattern">[^TD]+</param>
    </data>
  </define>
  <define name="DHMSduration">
    <data type="duration">
      <param name="pattern">-?P((\d+D)|T).*</param>
    </data>
  </define>

Two values belonging to one of these subtypes, for instance "P24M" (24 months) and "P1Y12M" (1 year and 12 months), can be compared without any issue since the conversion between the units used by each of the two subtypes is fixed.

This requirement for two subtypes derived from xs:duration has been expressed by the XQuery Working Group and the W3C XML Schema Working Group should add them to their release 1.1.

So far so good, but the W3C XML Schema recommendation specifies that derived types inherit all their properties from their base type.

Applied to this issue, that means that since the base type xs:duration has a partial order relation, any derived subtype should be considered as having a partial order relation. In other words, our workaround should not work for applications fully conformant with the W3C XML Schema recommendation!

Thus the question from Sperberg-McQueen asking if any application is following this requirement, while saying he wished that was not the case -- so that they can just "ignore the problem".

The fact that the co-chair of a Working Group might publicly wish that nobody strictly followed one of their recommendations is a good illustration of the limitations of the W3C XML Schema type system, which has no provision for creating new primitive datatypes.

While we cannot reproach the WG for the complexity of the time and date datatypes (this complexity is inherited from the Gregorian calendar), we can regret that the WG has wanted to impose universal datatypes good enough for everyone instead of having proposed a mechanism to create new primitive datatypes to match everyone's real needs.

The xs:duration doesn't match the need of a controller using fixes conversion rates between days, months and years (1 month = 30 days; 1 year=360 days) nor the need of astronomers needing a variable conversion rate between days and seconds.

We cannot reproach the WG for not having defined all these datatypes (many people think that, on the contrary, there are already too many predefined datatypes, but we can regret that applications needing such datatypes are blocked and cannot define them with all of their properties (or "fundamental facets" to use the expression of Sperberg-McQueen.

Instead of ignoring the issue, couldn't we try to fix it?

To be honest, the issue isn't simple and the corresponding part of ISO/DSDL seems to be pretty much stalled too!