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: 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