Re: Special note for CPP members

[Martin W Sachs <mwsachs@us.ibm.com>]

Duane,

First and foremost, the place for placing requirements on a team to develop
new functionality is the ebXML Requirements specification, not the TA
specification, so you need to communicate the desire for these requirements
to the Requirements team.  The TP section of the TA document thus far is an
exposition of the architecture and any words you put in should continue
that style.

Given any work on negotiation protocol today cannot possibly be in time for
ebXML Version 1, since the deadline has already passed, any prescriptive
words that you put in now about negotiation protocol will be empty, so
putting anything in will mislead the reader into thinking that the function
exists when it doesn't.  The place for prescriptive words is in the version
2 TA specification if ebXML continues to exist after May.

In addition, the whole question of whether it is appropriate to define a
normative composition and negotiation procedure at all is a major issue
that needs much wider discussion in ebXML.  Since the very first standards
(plumbing parts 100 years ago if memory serves me correctly), standards
have focused entirely on interoperability and have avoided constraining
implementations.  There are no interoperability issues in CPA composition
and negotiation as long as both CPPs conform to the ebXML CPA-CPP
specification.  Any tool that produces the correct CPA works regardless of
whether vendor A's tool uses the same procedures as vendor B's tool.

If you nonetheless want to put something in now, it should be something
like this:

   The CPA-CPP specification includes a non-normative appendix that
   discusses CPA composition and negotiation and includes advice as to
   composition and negotiation procedures.

That's all that  should be said.  Any more detail anticipates the results
of technical discussions not yet held and should not be said this early.

The part about "protocol SHALL be defined by the ebXML TP Project Team OR
by some other working group" should be presented to the Requirements team
for possible inclusion on their specification as a version 2 goal.

Also, please spell "Collaboration" correctly (NOT "Collaborative").

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



Duane Nickull <duane@xmlglobal.com> on 01/30/2001 01:12:24 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   matt@xmlglobal.com, Scott Hinkelman/Austin/IBM@IBMUS, "Welsh, David"
      <David.Welsh@nordstrom.com>, "Bob Haugen (E-mail)"
      <linkage@interaccess.com>, "Brian Hayes (E-mail)"
      <Brian.Hayes@Commerceone.com>, ebXML-StC <ebxml-stc@lists.ebxml.org>,
      ebxml-tp@lists.ebxml.org, Brian Eisenberg <BrianE@DataChannel.com>
Subject:  Re: Special note for CPP members



Marty Sachs wrote:

"Leaving aside the question of whether the TA document is supposed to
set
requirements or describe architecture, it is quite clear that since the
deadline for getting V1 function approved is already past (see the
current
QR schedule), the only possible description of composition and
negotiation
in the near term is whatever non-normative appendix that the TP team can
come up with in the next couple of weeks."

Marty et al:

Sorry to blindside you guys with this issue.  Brian Eisenberg and I were
just finishing the TA spec with the last comments when this arose from a
number of fronts.  There are obviously several issues that have to be
addressed somewhere in ebXML.

The ebXML Technical Architecture specification has a mandate to
prescribe minimal functional requirements to ensure that ebXML will
a) work;
b) meet the needs of businesses as described in the requirements
document
c) be technically feasable

The current point of view of several people is that the CPA negotiation
process must be specified in detail somewhere that is accessable and
part of the ebXML specifications.

Technical Architecture will not specify the CPA Negotiation process,
nor will it prescribe any unrealistic expecatations on the CPP group
(You guys have done an excellent job so far.  There was no way to even
know this would be an issue until we came this far.)

Also,  please be aware that the proposed wordign I sent out was from
myself and Brian.  It is not even presented to the TA team at this point
in time and they have not passed any judgement to the merits of the
statement.

So we have to address this problem.  It is the view of the Editors and
several people who have issued comments, that the CPA negotiation
process is key to ebXML functionality.  Therefore, we (the editors) will
leave it in and present it to the TA Team when the team votes on the
document.  We should agree with your team on the wording that you can
live with as well.

We would propose this but please reword it or give us an alternative
sentence.  The end goal is to define the CPA process, perhaps via
another group, at the earliest time possible.  IF it is not done for the
first ebXML v 1.0, we will have to live with manual CPA or perhaps
inconsistent CPA negotiation until v 2.0.  This is probably the best
anyone can do at this point in time.

Suggested wording:

"The CPA negotiation process SHALL be strictly defined. Issues such a
precedence, prioritization and the mechanics of the negotiation process
SHALL be addressed in the ebXML Specifications governing Collaborative
Protocol Agreements."

...

[Under "Non normative Implementation details"]

A CPA negotiation protocol SHALL be defined by the ebXML TP Project Team
OR by some other working group with a mandate to write a consistent
methodology for negotiating CPA's from CPP's."

Please note that this says "OR by some other working group.."

Please let us know your thoughts.

I also want to say that I and many other people are very impressed by
the quality of thought and work that has gone into the CPP/CPA to date.
It is obviously a lot more technical piece of work than many originally
envisioned and I , for one, have complete faith in your groups work and
abilities to make the system work.

Sorry again for the 11th hour red flag.

Duane Nickull