Backwards compatibility of the 2.0 errata

All,

One of the changes which has been made in the 2.0 errata is that we
renamed some data types.

It's the following two data types:

http://www.w3.org/TR/2002/WD-xquery-operators-20020816#dayTimeDuration
http://www.w3.org/TR/2002/WD-xquery-operators-20020816#yearMonthDuration

Their definition referred to a draft of XPath 2, and once XPath 2 was
finished, we updated the errata so their definition instead refers to
the approved version of XPath 2. We also updated their names to

urn:oasis:names:tc:xacml:2.0:data-type:dayTimeDuration
urn:oasis:names:tc:xacml:2.0:data-type:yearMonthDuration

We thought it prudent to not change the behavior of existing identifiers
I presume.

However, this introduces a problem. The following functions make use of
these data types:

urn:oasis:names:tc:xacml:1.0:function:dayTimeDuration-equal
urn:oasis:names:tc:xacml:1.0:function:yearMonthDuration-equal
urn:oasis:names:tc:xacml:1.0:function:dateTime-add-dayTimeDuration
urn:oasis:names:tc:xacml:1.0:function:dateTime-add-yearMonthDuration
urn:oasis:names:tc:xacml:1.0:function:dateTime-subtract-dayTimeDuration
urn:oasis:names:tc:xacml:1.0:function:dateTime-subtract-yearMonthDuration
urn:oasis:names:tc:xacml:1.0:function:date-add-yearMonthDuration
urn:oasis:names:tc:xacml:1.0:function:date-subtract-yearMonthDuration

They have now been redefined in the errata to accept arguments of the
new types, which breaks existing policies and implementations.

I can see the following alternatives:

1) Let it be like this and let implementations perform some trickery to
work with different combinations. Or let implementations choose if they
want to conform to the errata or to the original standard.

2) Retract the updated data types.

3) Also change the names of the functions.

I think the third option is best. This allows the old and new
identifiers to co-exist and we move forward only the new identifiers to
3.0, so eventually the world will migrate to the new identifiers.

I wouldn't mind the second option either. In the end, there was not any
problem with the old functions and data types, except that they
referenced a working draft of another standard. But they were
technically correct, so perhaps it is not necessary to make these
changes to the existing XACML 2.0 for no clear reason. (BTW, would a
change of this kind be allowed by the OASIS errata process?) For 3.0 we
could update them and discontinue referencing the old identifiers if we
want to tidy up.

I don't think we should do the first alternative. It's bound to lead to
all kinds of confusion and interoperability issues. Besides it seems
like a bad idea to redefine existing identifiers for no actual error in
them.

Regards,
Erik