[ebxml-cppa] Current backlog of editorial clarifications for end ofSeptember edits

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Please check this compilation of editorial fixes for end of September.

To be discussed at Friday CPPA teleconference.

Clarification of signature element

 

http://lists.oasis-open.org/archives/ebxml-cppa/200208/msg00018.html

Also http://lists.oasis-open.org/archives/ebxml-cppa/200208/msg00019.html

 

I just realized that we cannot change the schema of the ds:Signature

element because it has to have minOccurs="1" to apply to the CPP as well as

the CPA.

 

However, the cited paragraph still has problems because it mis-states the

cardinality of ds:Signature and implies that there could be a CPA involving

only one Party. Therefore, I propose that we make an editorial correction

as given by the second of the alternatives in my original note.  The

proposed text is:

 

The Signature element, if present, is made up of one to three ds:Signature

elements. The CPA can be signed by one or both Parties. It is RECOMMENDED

that both Parties sign the CPA. For signing by both parties, one Party

initially signs. The other Party then signs over the first Party

signature. The resulting CPA MAY then be signed by a notary.

 

Note that the revised paragraph includes the possiblity that the CPA might

be signed by only one Party, which is present in the current draft

specification.

 

Clarification of CanSend, CanReceive, and Nesting

http://lists.oasis-open.org/archives/ebxml-cppa/200208/msg00053.html

 

 

I believe this is our first public review comment!

 

Someone, please review the questions and my answers to see if we need

More explanatory text in the specification.

 

What is the purpose of CanSend and CanReceive

elements in CPP. Etc.

 

Is there a consensus on what needs to be added here?

 

Clarification of “signed” as a status value.

http://lists.oasis-open.org/archives/ebxml-cppa/200208/msg00022.html

 

I agree with Dale's proposed words,

 

   "signed", meaning that the CPA has been "signed" by

   one or more of the Parties...

 

We should also include: "A note about the process -- that the first

signer must change the value-- can also be added."

 

The current version of the CPPA spec states, regarding the value of the

value attribute of the status element (line 3015):

 

     "signed", meaning that the CPA has been "signed" by the Parties...

 

I believe that this is incorrect.  The value of the value attribute must

Be set to "signed" just before the first party signs.  It cannot be

Modified after that without invalidating the first party's signature. I suggest

changing the statement to:

 

     "signed", meaning that the first Party has signed the CPA...

 

I also suggest adding a note clarifying why the value has to be set to

"signed" when the first party signs.  For example:

 

Version so far

 

NOTE:  The value of the Status element’s value  is set to "signed" before the first party signs. Even though excluding the Status element’s value attribute from a signature might be technically feasible,  it is preferable to change the attribute value to signed prior to the first signature, and maintain it as “signed” for any subsequent signature.

 

Fix transposed text

http://lists.oasis-open.org/archives/ebxml-cppa/200208/msg00001.html

 

In looking for negotiation text in Appendix E of CPPA V2, I came across the following:

Line 6569-6571 states: "In order to represent binding details for synchronous sending, the convention is adopted whereby the CanSend element for a Receiver is placed under its CanReceive element. This is illustrated by:" Yet the CPP snippet directly below has CanReceive elements as child elements of the CanSend element.

Line 6633-6635 states: "This subordination will also carry over to the synchronous receiving side, in which its CanReceive element(s) is (are) under the CanSend element used to represent the initial sending of a request. An illustration from Company Bā€™s synchronous binding is:" Yet the CPP snippet directly below has CanSend elements as child elements of the CanRecieve element.

 

Fix of Certificate cardinality

2. http://lists.oasis-open.org/archives/ebxml-cppa/200207/msg00023.html

 

The consensus at today's CPPA teleconference was to:

 

1. Add a "minoccurs=0" qualification

to the 2.0 schema for the Certificate element.

 

2. Adjust text in the specification to reflect this change,

in the appendix for the schema  and in the Certificate

documentation section.

 

Clarification of semantics for contentless ebXMLSenderBinding and ebXMLReceiverBinding

 

 One other text addition is under study to specify what it means

if the ebXML[Sender|Receiver]Binding element has no content. A proposal

is that it would default to SOAP or maybe SOAP with attachments?

 

http://lists.oasis-open.org/archives/ebxml-cppa/200208/msg00010.html

Here are the results of my analysis of omitting all child elements of

ebXMLSenderBinding and ebXMLReceiverBinding from the CPA. When I finished

the analysis, it wasn't obvious to me that any additional explanation is

needed in the CPPA spec, though a comment that it is permissible to omit

all the child elements might be appropriate.  Note also that the discussion

below also includes the attributes of MessagingCharacteristics.

 

Clarification of role and mimeparameter attributes in SimplePart

 

http://lists.oasis-open.org/archives/ebxml-cppa/200206/msg00030.html

 

For the SimplePart element, the schema includes attributes role and (via pkg.grp) mimeparameters. However these are not mentioned in the textual definition of SimplePart and do not appear in any of the examples.

 

http://lists.oasis-open.org/archives/ebxml-cppa/200206/msg00035.html

 

The role attribute (actually xlink:role) under SimplePart found in the 2.0 schema is mentioned on line 2732 (on page 64) in the spec. It is also referenced in Appendix F, and is equivalent to the xlink:role attribute under the Reference element used in the ebMS spec.

 

The mimeparameters attribute has been included in the schema since CPP/A 1.0. Its omission from the 2.0 spec is inherited from the 1.0 spec and needs to be fixed.

 

Clarification of location attribute in NamespaceSupported element.

 

http://lists.oasis-open.org/archives/ebxml-cppa/200206/msg00029.html

 

In CPPA version 2, the NamespaceSupported element has a location attribute. There is no definition of the location attribute in the specification. This is not a simple typo. Every instance of NamespaceSupported, including the schema, has a location attribute. Should it be changed to schemaLocation or given a definition that is the same as schemaLocation?

Along these lines, there is a related item which is probably a typo. The definition of NamespaceSupported is "The NamespaceSupported element identifies the namespaces supported ..." To me, this implies that more than one namespace can be listed under this element. However, that is not likely since the namespace is identified by the value of the element. I believe that something like this is more precise: "The NamespaceSupported element may be included zero or more times. Each occurence of the NamespaceSupported element identifies one namespace supported..."

http://lists.oasis-open.org/archives/ebxml-cppa/200206/msg00029.html

 

I agree with you that schemaLocation would have been a more appropriate attribute name than location.

 

I also agree with you that there is a typo in the description of the NamespaceSupported element and that your rephrasing is more precise and preferrable.