[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.
It seems to me that referring to the version of the schema from the instance document (CPP and CPA) is a good thing to do so that prospective trading partners can tell if they are using the same version of the schema. Any changes to the schema that affect function must result in a new attribute in the schema. This is probably everything but comment elements. I suggest treading lightly and incrementing the schema version number by, say .01, to be sure we don't end up incrementing the integer portion for small changes. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* Arvola Chan <arvola@tibco.com To: Dale Moberg <dmoberg@cyclonecommerce.com>, Christopher Ferris > <chris.ferris@sun.com> cc: "Cppa (E-mail)" <ebxml-cppa@lists.oasis-open.org> 03/24/2002 11:29 Subject: Re: [ebxml-cppa] Versioning for CPP: new proposal to drop version PM attribute on CPP. 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> > ---------------------------------------------------------------- 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