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] editorial comment on V2 - correction


Marty, even for a CPA, minOccurs must be 1, because both parties
cannot sign it simultaneously.  There will be some point in time that
the (proposed?) CPA will exist with only one party's signature, before
the other has received it, added his signature, and returned the final
copy.

Your new wording allows this to take place.

--Pete
Pete Wenzel <pete@seebeyond.com>
SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)

Thus spoke Martin W Sachs (mwsachs@us.ibm.com) on Fri, Aug 16, 2002 at 02:11:05PM -0400:
> 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
> $)Cinitially signs. The other Party then signs over the first Party!/s
> 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.
> 
> 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
> *************************************************************************************
> ----- Forwarded by Martin W Sachs/Watson/IBM on 08/16/2002 01:51 PM -----
>                                                                                                                                         
>                       Martin W Sachs                                                                                                    
>                                                To:       ebxml-cppa@lists.oasis-open.org                                                
>                       08/15/2002 06:14         cc:                                                                                      
>                       PM                       From:     Martin W Sachs/Watson/IBM@IBMUS                                                
>                                                Subject:  editorial comment on V2                                                        
>                                                                                                                                         
>                                                                                                                                         
>                                                                                                                                         
> 
> 
> 
> I just came across the following minor editorial and schema problem with
> the CPA Signature element.  Lines 3152-3155 state:
> 
> The Signature element, if present, is made up of one or more ds:Signature
> elements. In a CPA involving two Parties, there can be up to three ds:
> Signature elements within the Signature element. The CPA is initially
> signed by one of the two Parties. The other Party could then sign over the
> first Party!/s signature. The resulting CPA MAY then be signed by a notary.
> 
> Since a CPA can never involve only one Party, that goes without saying
> (second sentence). Also, if the Signature element is present, there can be
> either 2 or 3 ds:Signature elements, never only one unless we want to allow
> for signing by only one Party.  I suggest fixing the schema to specify a
> cardinality of minOccurs="2" maxOccurs="3", and changing the paragraph to:
> 
> The Signature element, if present, is made up of two or three ds:Signature
> elements. The CPA is initially signed by one of the two Parties. The other
> Party then signs over the first Party!/s signature. The resulting CPA MAY
> then be signed by a notary.
> 
> If the team prefers to keep open the option of signing by only one Party,
> then no change is needed to the schema and the paragraph would be as
> follows:
> 
> 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, the first
> Party signs. The other Party then signs over the first Party!/s signature.
> The resulting CPA MAY then be signed by a notary.
> 
> 
> 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
> *************************************************************************************
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>


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


Powered by eList eXpress LLC