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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[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.


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?

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