[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] Versioning for CPP: new proposal to drop versionattribute on CPP.
Dale Moberg wrote: > If this is what the version attribute was for, > we do not have it documented correctly. > > Was this also the intent for the version attribute > on CollaborationProtocolAgreement? yes, to the best of my recollection, it was the same for both. > > Arvola, are we still committed to a schema > versioning scheme that makes this use of a > version attribute useful> > > Dale > > -----Original Message----- > From: Christopher Ferris [mailto:chris.ferris@sun.com] > Sent: Friday, March 22, 2002 11:56 AM > To: Dale Moberg > Cc: Cppa (E-mail) > Subject: Re: [ebxml-cppa] Versioning for CPP: new proposal to drop > version attribute on CPP. > > > My recollection was the the version attribute applied to > the CPP schema version, not the instance of a given CPP > that was somehow modified. It has the same semantics > as the version attribute in XSLT[1]. > > Cheers, > > Chris > > [1] http://www.w3.org/tr/xslt > > Dale Moberg wrote: > > >>Hi, >> >>I am stumped on why we have versioning for a CPP. >> >>The cppid is to supply a unique identifier for a CPP. >>For the sake of argument, let's say that this means >>that no two CPPs can have the same cppid. >> >>When are CPPs the same? For the sake of argument, let us say >>that CPPs are the same when their hash values, for >>the purpose of signing, are the same. Conversely, we >>have two CPPs when their hash values differ. >> >>So if we changed the version _value_, and left all else >>the same in a CPP, we would have two CPPs with different >>hash values and the same cppid. This contradicts >>our assumption that no two CPPs have the same cppid. >> >>Therefore, we cannot really have _two_ CPPs that differ >>only by version number (on the previous assumptions). >> >>So we need to say what it means for CPPs to differ >>enough to be different versions, but not differ >>enough to warrant having different cppids. I think >>this is either a rabbit hole or a rat hole, and >>I now think that either >>way we should avoid entering therein. >> >>I am now inclined to say we should drop the version attribute >>on the CollaborationProtocolProfile element. We should also >>just say that the cppid value should be a globally unique >>identifier. >> >>Should we say anything about format of that guid? >>Should we reference some other standard that has >>solved the issue of how collisions >>in creation of this identifier are avoided? >>If so, does anyone know what standard would be good >>to reference here? >> >> >> >> >> >> >> >> >> >> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC