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: [ebxml-cppa] Updated files


Peter:
 
Attached please find a zip file that contains all of my change contributions to the 1.03 draft. A brief summary of the changes are as follows:
 
ebcpp 1.03.doc: please refer to change tracking within the Word document
3A4.xml: updated uuid for business process as bpid:icann:rosettanet.org:3A4$2.0
draft-cpa-example-09.xml: updated service name as bpid:icann:rosettanet.org:3A4$2.0
draft-cpp-example-companyA-09.xml: updated service name as bpid:icann:rosettanet.org:3A4$2.0
draft-cpp-example-companyB-09.xml: updated service name as bpid:icann:rosettanet.org:3A4$2.0
draft-cpp-cpa-09.xsd:added wildcard elements including the one under ActionContext requested by Hima/Tony.
 
Regards,
-Arvola
-----Original Message-----
From: Peter Ogden <pogden@cyclonecommerce.com>
To: Arvola Chan <arvola@tibco.com>; Tony Weida (E-mail) <rweida@hotmail.com>
Cc: Dale Moberg <dmoberg@cyclonecommerce.com>
Date: Tuesday, January 08, 2002 3:31 PM
Subject: RE: Possible conflict in version 1.03 schema changes

Arvola,
 
That  will be fine.
 
Peter
-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Tuesday, January 08, 2002 4:09 PM
To: Tony Weida; Peter Ogden
Cc: Dale Moberg
Subject: Re: Possible conflict in version 1.03 schema changes

Peter:
 
I suspect your changes are more extensive than mine for this iteration. Is it possible I send you a marked up copy of 1.02 with my changes, and you incorporate those changes into a vesion with your changes, before turning the combined changes over to Tony?
 
With respect to wildcard elements, I may just add one section identifying the set of elements that can carry wildcard sub-elements, without modifying the sections that correspond to those elements.
 
Thanks,
-Arvola
-----Original Message-----
From: Tony Weida <rweida@hotmail.com>
To: Arvola Chan <arvola@tibco.com>; Peter Ogden <pogden@cyclonecommerce.com>
Cc: Dale Moberg <dmoberg@cyclonecommerce.com>
Date: Tuesday, January 08, 2002 2:38 PM
Subject: Possible conflict in version 1.03 schema changes

Arvola and Peter,
 
I understand that Arvola wants to submit wildcard-related schema changes this week for version 1.03.  I also understood that Peter wanted to submit his schema changes, pending sufficient feedback.  So ...
 
Peter, do you currently expect to submit for 1.03?
 
If the answer is yes, can you two coordinate your changes?  For example, I could turn over the 1.02 document to either of you, then ask the other to make changes on top of that.  Since no one else has committed changes for version 1.03, I'd take the result and make my own updates for 1.03 afterwards.  I'm open to various possibilities, as long as we communicate to prevent unnecessary conflicts.
 
Thanks,
Tony
 
P.S.  I was on jury duty today and will be again tomorrow (at least) so I won't have access to email during the day.
----- Original Message -----
Sent: Tuesday, January 08, 2002 12:28 PM
Subject: Re: [ebxml-cppa] Adding #wildcard element to provide extensibility

I propose to add wildcards of the form:
 
<any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded">
 
A minimal extension would be to add this only to the CollaborationProtocolProfile and CollaborationProtocolAgreement elements. Another extreme possibility is to add such a sub-element to all elements within the CPP/A schema.
 
My recommendation is to take some middleground, to add a wildcard sub-element to each of the following:
  • CollaborationProtocolProfile
  • CollaborationProtocolAgreement
  • Selected child elements of CollaborationProtocolProfile and CollaborationProtocolAgreement, including
    • PartyInfo
    • SimplePart
    • Packaging
  • All child elements of PartyInfo, including
    • PartyId
    • PartyRef
    • CollaborationRole
    • Certificate
    • DeliveryChannel
    • SecurityDetails
    • Transport
    • DocExchange
    • OverrideMshActionBinding
  • Any other element identified on a case by case basis. So far, this includes
    • ActionContext (identified by Hima)
Unless I hear objections and/or other recommendations, I like to submit these schema changes to the 1.03 draft.
 
Regards,
-Arvola
-----Original Message-----
From: Tony Weida <rweida@hotmail.com>
To: Arvola Chan <arvola@tibco.com>; ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>
Date: Wednesday, December 19, 2001 10:26 AM
Subject: Re: [ebxml-cppa] Adding #wildcard element to provide extensibility

Sounds good to me.  --  Tony
----- Original Message -----
Sent: Wednesday, December 19, 2001 12:51 PM
Subject: [ebxml-cppa] Adding #wildcard element to provide extensibility

In the Messaging spec, #wildcard element content is supported in every SOAP extension as well as in all of their major repeating sub-elements.
 
To provide extensibility in the CPP/CPA structure, I think it may be useful to allow #wildcard extensions in most elements in the CPP/A schema.
 
I know RosettaNet's TPA Foundational Program would like to express message exchange requirements in terms of CPP/A. However, not enough initial work has been done to determine if there are major show stoppers. Allowing namespace qualified wildcard extensions may help industry groups like RosettaNet to adopt the use of CPP/A.
 
If there is support for this idea, I like to include such wildcard extensions in the 1.02 version of the spec.
 
Thanks,
-Arvola

20020109.zip



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC