[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.
Arvola, No, I was referring to the version attribute within the CPP/A instance document, not the schema (although the values were meant to be the same for both). Cheers, Chris Arvola Chan wrote: > Dale and Chris: > > In the top-level Schema element in the XSD, there is a version attribute. I > wonder if Chris is referring to that version attribute as opposed to the > version attribute within the CollaborationProtocolProfile element. > > The sections related the the version attribute of the Schema element, and > the version attribute of the CollaborationProtocolProfile element have > pretty much stayed unchanged since the 1.0 CPPA spec. Here are excerpts from > the 1.0 spec: > > " > 4.4 Version of the Specification > Whenever this specification is modified, it SHALL be given a new version > number. The value of the version attribute of the Schema element of the XML > Schema document SHALL be equal to the version of the specification. > " > > " > 7.4 CollaborationProtocolProfile element > The CollaborationProtocolProfile element is the root element of the CPP XML > document. > The REQUIRED [XML] Namespace[XMLNS] declarations for the basic document are > as follows: > · The default namespace: > xmlns="http://www.ebxml.org/namespaces/tradePartner", > · XML Digital Signature namespace: > xmlns:ds="http://www.w3.org/2000/09/xmldsig#", > · and the XLINK namespace: xmlns:xlink="http://www.w3.org/1999/xlink". > > In addition, the CollaborationProtocolProfile element contains an IMPLIED > version attribute that indicates the version of the CPP. Its purpose is to > provide versioning capabilities for instances of an enterprise's CPP. The > value of the version attribute SHOULD be a string representation of a > numeric value such as "1.0" or "2.3". The value of the version string SHOULD > be changed with each change made to the CPP document after it has been > published. > " > > I agree with Marty that there is no need for a version attribute in the > CollaborationProtocolProfile element. The version attribute for the Schema > element in the XSD will initially be set to 2.0. Since the CPPA namespace > will be > "http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-cpa-2_0.xsd" and > will resolve to a schema located at the same URI, we need to make provision > for the possibility that errors in the schema may be discovered after the > spec and the schema have been published. Rather than just replacing the > contents of the XSD located at the namespace URI, it may be desirable to > update the version attribute of the schema element to indicate that an > updated version of the schema has been placed at the namespace URI. > > The CPP/A TC needs to agree on a scheme for how the schema may be updated to > deal with bug fixes and preferrably describe the chosen scheme within the > specification itself. > > -Arvola > > ----- Original Message ----- > From: "Dale Moberg" <dmoberg@cyclonecommerce.com> > To: "Christopher Ferris" <chris.ferris@sun.com>; "Arvola Chan (E-mail)" > <arvola@tibco.com> > Cc: "Cppa (E-mail)" <ebxml-cppa@lists.oasis-open.org> > Sent: Friday, March 22, 2002 11:35 AM > Subject: RE: [ebxml-cppa] Versioning for CPP: new proposal to drop version > attribute 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