[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] Current backlog of editorial clarifications for endof September edits
These fixes look good. Let's make them as proposed. I have some miscellaneous comments below. Suresh Damodaran submitted a set of comments on 6/4/02 to which Dale made an an initial reply the same day. I don't recall any decision on disposition of those comments and I don't see them in the email below. Misc. comments: "Clarification of CanSend...": I suggest adding a non-normative note saying that there is no known use case for more than one level of nesting. It probably should be under both CanSend and CanReceive. "Clarification of 'signed'...": Typo in the proposed non-normative note. The first line should be: "NOTE: The value of the Status element's value attribute is..." (added the word "attribute"). "...contentless ebXML SenderBinding...": It would be a good idea to add a comment (both under ebXMLSenderBinding and ebXMLReceiverBinding) that it is permissible to omit all child elements. One could go farther and say what that results in although, as I pointed out earler, it should be pretty clear from their definitions what is meant by omitting all of them. "Clarification of role..." Comment on the comment: The xlink:role attribute is actually on line 2708. 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 ************************************************************************************* Dale Moberg <dmoberg@cycloneco To: "Cppalist (E-mail)" <ebxml-cppa@lists.oasis-open.org> mmerce.com> cc: Subject: [ebxml-cppa] Current backlog of editorial clarifications for end of 09/18/2002 06:59 September edits PM Please check this compilation of editorial fixes for end of September. To be discussed at Friday CPPA teleconference. Clarification of signature element <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC