[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