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