OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]