[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Agenda for Friday Feb 27 OASIS ebXML teleconference 8 AM PST, 11 EST, 5 PM CET
Probably 20 minutes for CPPA. Negotiation subteam follows CPPA 706 679 5113 877 204 8750 4806272648# Please finish final reviews of the text in the attachments. Two deal with errata agreed to previously. One is a new proposed resolution to a public comment. Provisional Agenda 1. Announcements 2. Issues and discussion a. Review of proposed resolution of cardinality discrepancy (Change to contents of 2 XML comments in some illustrative XML in the text that is misleading following a schema cardinality change made prior to approval.) 3. Negotiation session
Convention for indicating Packaging consisting of a single MIME entity of a non-composite, non-encapsulating type: Until the OASIS ebXML TC approves an updated version of the version 2.0 CPPA core specification, the convention for indicating Packaging that consists of one SimplePart will be as follows: The mimetype value for the Composite and the mimetype value of the SimplePart referred to by the Constitutent shall be identical. In that case, there will be only one Constituent element in the Composite, and only one Composite in the CompositeList. The mimeparameters attribute on the Composite element would typically then be omitted. In Section 8.6.2 of the specification version 2.0, the following sentence needs The mimetype attribute provides the value of the MIME content-type for this Message part, and this will be some MIME composite type, such as "multipart/related" or "multipart/signed". When the preceding convention is used, the Composite mimetype attribute can have simple mime types, such as “text/xml,” ”application/xml,” and others as appropriate. When the mimetype value for the Composite is a composite type (such as “multipart/*” or “message/*”), then the Packaging element indicates that a composite type includes Constituents of SimpleParts (and possibly other parts) as is typical when using MIME for attachments. Future direction: When updates to the version 2.0 CPPA core specification are made, it is expected that the schema for the Packaging element will be updated to allow a choice over CompositeList and Constituent. When a Constituent occurs, the Packaging is just the SimplePart to which the Constituent refers. The convention introduced above will, however, be retained, although deprecated for new applications. The anticipated schema change in updates to 2.0 will be from: <element name="Packaging"> <complexType> <sequence> <element name="ProcessingCapabilities"> <complexType> <attribute name="parse" type="boolean" use="required"/> <attribute name="generate" type="boolean" use="required"/> </complexType> </element> <element name="CompositeList" maxOccurs="unbounded"> <complexType> <choice maxOccurs="unbounded"> <element name="Encapsulation"> <complexType> <sequence> <element ref="tns:Constituent"/> </sequence> <attributeGroup ref="tns:pkg.grp"/> </complexType> </element> <element name="Composite"> <complexType> <sequence> <element ref="tns:Constituent" maxOccurs="unbounded"/> </sequence> <attributeGroup ref="tns:pkg.grp"/> </complexType> </element> </choice> </complexType> </element> </sequence> <attribute ref="tns:id" use="required"/> </complexType> </element> to <element name="Packaging"> <complexType> <sequence> <element name="ProcessingCapabilities"> <complexType> <attribute name="parse" type="boolean" use="required"/> <attribute name="generate" type="boolean" use="required"/> </complexType> </element> <choice> <element name="CompositeList" maxOccurs="unbounded"> <complexType> <choice maxOccurs="unbounded"> <element name="Encapsulation"> <complexType> <sequence> <element ref="tns:Constituent"/> </sequence> <attributeGroup ref="tns:pkg.grp"/> </complexType> </element> <element name="Composite"> <complexType> <sequence> <element ref="tns:Constituent" maxOccurs="unbounded"/> </sequence> <attributeGroup ref="tns:pkg.grp"/> </complexType> </element> </choice> </complexType> </element> <element ref="tns:Constituent"/> </choice> </sequence> <attribute ref="tns:id" use="required"/> </complexType> </element>
The issue raised in the Public Comment list by Louise Peres (louise.peres@francetelecom.com) was “There is an differenece between the document ebCPP2_0.pdf and the schema cpp-cpa-2_0.xsd. line 668 about Certificate, it's written "one or more" line 771, about SecurityDetails, it's written "one or more". The lines referred to are in an example fragment within the text. Below is the fragment with the lines in questioned numbered. <tp:PartyInfo tp:partyName="..." tp:defaultMshChannelId="..." tp:defaultMshPackageId="..."> <tp:PartyId tp:type="..."> <!-- one or more --> … </tp:PartyId> <tp:PartyRef xlink:href="..."/> <tp:CollaborationRole> <!-- one or more --> ... </tp:CollaborationRole> 668 <tp:Certificate> <!-- one or more --> ... </tp:Certificate> 771 <tp:SecurityDetails> <!-- one or more --> ... </tp:SecurityDetails> <tp:DeliveryChannel> <!-- one or more --> </tp:DeliveryChannel> <tp:Transport> <!-- one or more --> ... </tp:Transport> <tp:DocExchange> <!-- one or more --> ... </tp:DocExchange> <tp:OverrideMshActionBinding> <!-- zero or more --> ... </tp:OverrideMshActionBinding> </tp:PartyInfo> We decided to change PartyInfo so that agreements involving no PKI alignments are OK so we have as Louise Peres noted: “In the schema,in the PartyInfo definition, the elements Certificate and SecurityDetails have minOccurs="0".” I propose that we add an errata stating Comments at the end of lines 668 and and 771 of Collaboration-Protocol Profile and Agreement Specification, Version 2.0 stating “<!-- one or more -->” are incorrect. Each comment should be changed to read “ <!-- zero or more -->.” I will also send a note to Louise Perez thanking him for his correction.
Sacha has cleaned up the CPP and CPA examples. I propose adding text with the pattern in the following to the errata file. Actually, I need to work with the OASIS webmaster on the actual URLs for the new file references and how to upload. So the precise values of the URLs may have to be edited slightly. I would like not to have to use the “php” style URLs, but rather URLs under the http://www.oasis-open.org/committees/ebxml-cppa/schema/ directory. ================= Non-normative Appendices A and B of Collaboration-Protocol Profile and Agreement Specification , Version 2.0 contain sample CPP and CPA instance documents. These appendices are also available in files at: http://www.oasis-open.org/committees/schema/cpp-example-companyA-2_0b.xml http://www.oasis-open.org/committees/schema/cpp-example-companyB-2_0b.xml http://www.oasis-open.org/committees/schema/cpa-example-2_0b.xml Both the appendices and the files that extract the sample data contain several small errors. Files that provide corrections to these errors will be made available at the following locations as follows: - an updated sample CPP A http://www.oasis-open.org/committees/schema/cpp-example-companyA-2_0c.xml - an updated sample CPP B http://www.oasis-open.org/committees/schema/cpp-example-companyB-2_0c.xml - an updated sample CPA http://www.oasis-open.org/committees/schema/cpa-example-2_0c.xml In the difference files listed next, lines beginning with "-" indicate that the line is removed by the following line beginning with "+". - a file showing the difference between updated CPP A and original CPP A http://www.oasis-open.org/committees/schema/cpp-example-companyA-2_0bc.diff - a file showing the difference between updated CPP B and original CPP B http://www.oasis-open.org/committees/schema/cpp-example-companyB-2_0bc.diff - a file showing the difference between updated CPA and original CPA http://www.oasis-open.org/committees/schema/cpa-example-2_0bc.diff
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]