[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa-negot] 9/16/2002: Message Contents Comments
Monica,
I have some replies to your comments, labelled MWS:
- Unique Business Message ID – uniquely identify the current Business
Message within the scope of one negotiation dialog. Is this the MessageID
from ebMS?
MWS: I suggest NOT using the MessageId from ebMS. We would like to keep
the negotiation protocol independent of what messaging service is used
underneath. Such a messaging service might not have a usable message ID.
So, in my mind, this message ID should be defined at the negotiation
protocol level, not at the messaging service level.
- Non-leaf node will indicates if? the entire subtree is subject to the
corresponding change action. If both Non-leaf node AND its children leaf
node are present in Negotiation Content, then the Negotiation Content
SHOULD be considered invalid. Jean, these sentences need clarification.
MWS: I agree that clarification is needed. Non-leaf node indicates that
this node and the whole subtree below this node is subject to negotiation.
If a non-leaf node is shown, its children SHALL NOT be shown since that
could introduce contradictions. There is an assumption that a non-leaf node
cannot be negotiable independent of its descendents. A possible exception
is that an attribute of a non-leaf node might be negotiable without
intending to allow anything else in that subtree to be negotiable. That
can be indicated by showing the XPATH to that attribute. So one might
consider the following rules:
1. If the XPATH expression leads to a non-leaf element, that whole subtree
is negotiable.
2. If the XPATH expression leads to any attribute, it only means that that
attribute is negotiable and doesn't imply anything about the containing
element or the rest of the subtree descended from the element containing
that attribute.
3. If the XPATH expression leads to a leaf node (element), only that
element and its contained attributes are negotiable.
Note that the above rules are really NDD rules to which the message
definitions will conform.
MWS: We need to be careful, in all of these discussions, not to introduce
complexity that may get in the way of having a usable version 1 by the end
of December.
- Negotiation Dialog ID is used to identify a particular negotiation dialog
thread. Negotiation Dialog ID can be CPA ID. The value of CPAID could be
used as the value for Negotiation Dialog ID. If the CPA ID is used, this
should be allowed to be null or the CPA ID element must be null to infer
that the CPA ID is used for the Negotiation Dialog ID, correct?
MWS: Here, the intent is that the value of the CPA ID can be used as the
Negotiation Dialog ID. I don't think that it is really necessary to say
whether or not the Negotiation Dialog ID is the same as the CPA ID. This
statement is only intended to suggest that an implementation may chose to
set the value of Negotiation Dialog ID equal the CPA Id rather than
generating a separate Negotiation Dialog ID. In other words CPA ID and
Negotiation Dialog ID both SHALL contain values. However, they might or
might not contain the same value. It IS intended that CPA ID come from the
cpaId attribute in the CPA template.
Party A doesn’t need to send anything to Party B at the time of expiration
happens. Party A records the current process as “expired”, and when Party
B finally sends a reply, if it is anything other than a “reject”, then
Party A can send a “reject” back, list the status as “expired”. You may
wish to differentiate ‘expired’ from the lack of a response vs. the
‘Expiration Date’ for an accepted negotiated CPA. This could alleviate some
confusion.
MWS: I agree.
- Unable to fulfill Security Requirements
- Proposed Security Policy is inadequate Differentiate this item and
the one above.
MWS: The first bullet may mean that the proposed security requirements are
too stringent or that the proposed certificate authority is unacceptable.
The second bullet may mean that the proposed security policy is too weak.
I agree that clarification is needed.
- All elements specified in one’s NDD indicate negotiable items. The
elements that are not mentioned in a party’s NDD shall be interpreted as
NON-NEGOTIABLE. Given the first ‘offer’ starts the negotiation, should the
entire CPA template be provided. That infers you will have negotiable and
non-negotiable items. If they are not included, that infers that the
trading partners must have a copy of their trading partner agreement to see
non-negotiable items for evaluation purposes. How does this affect the
business interaction? Would it not be advisable to at least include all
items and tag them as negotiable or non-negotiable for the first ‘offer?’
MWS: Yes, the entire CPA template SHALL be provided with the initial
offer. The CPA template is really the offer; the NDD indicates what is
negotiable in the CPA template.
Some of this will become a lot clearer when I distribute a complete draft
specification after the open work items get farther along.
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
*************************************************************************************
Monica Martin
<mmartin@certivo. To: Martin W Sachs/Watson/IBM@IBMUS, Jean Zheng <jzheng@vitria.com>
net> cc: ebxml-cppa-negot@lists.oasis-open.org, Monica Martin
<mmartin@certivo.net>
09/16/2002 12:56 Subject: [ebxml-cppa-negot] 9/16/2002: Message Contents Comments
PM
See a few questions inline in the document attached.
Thank you.
Monica J. Martin
Program Manager
Drake Certivo, Inc.
208.585.5946
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Sunday, September 08, 2002 7:50 PM
To: Jean Zheng
Cc: ebxml-cppa-negot@lists.oasis-open.org
Subject: Re: [ebxml-cppa-negot] message content version 09062002
Jean,
I prefer the style of the CPPA specification, element by element in
depth-first fashion, with example fragments in the text.
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
************************************************************************
*************
"Jean Zheng"
<jzheng@vitria.co To: "Martin W
Sachs" <mwsachs@us.ibm.com>
m> cc:
<ebxml-cppa-negot@lists.oasis-open.org>
Subject:
[ebxml-cppa-negot] message content version 09062002
09/06/2002 07:58
PM
Here is the updated Message Content I have promised.
I've gone through Marty's discussion with Bob and Monica regarding
adding a
"change list" to CPA template, and I have included a paragraph in
section
1.1 that hopefully has captured your suggestions.
Regarding what to include in the negotiation spec. I think we will
probably follow the style of CPPA spec, where we have element by element
descriptions of each item of message content. Or else, we can start
with
the current structure of this msg content doc. As we flush out more
details, they will grow accordingly. What do you think?
I will be working on the schema for the next few weeks. :)
Jean
#### NegotiationMessageContent.doc has been removed from this note on
September 08 2002 by Martin W Sachs
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
(See attached file: NegotiationMessageContent_090602.doc)
Attachment:
=?UTF-8?B?TmVnb3RpYXRpb25NZXNzYWdlQ29udGVudF8wOTA2MDIuZG9j?=
Description: MS-Word document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC