Re: [xacml] Backwards compatibility of the 2.0 errata

[Bill Parducci <bill@parducci.net>]

I am in favor of #3, it seems to provide the cleanest path moving  
forward. I suspect most adopters would gladly trade the need to  
migrate to new function [names] for the ability to reference an  
approved spec.

b

On Jun 4, 2008, at 3:19 AM, Erik Rissanen wrote:

> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs  
> in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php