RE: updated requirements specification

[Scott Hinkelman/Austin/IBM <srh@us.ibm.com>]

David B. made statement that resolving at the f2f is best. I agree. I am
finished on this.
Klaus made statement on terminology to the effect of in the end will be
what UN/CEFACT uses.
Exactly what this means, or insinuates, should be discussed also at the f2f
in this context.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Tony Weida <TonyW@EDIFECS.COM> on 10/19/2000 08:46:11 PM

To:   "Burdett, David" <david.burdett@commerceone.com>, Scott
      Hinkelman/Austin/IBM@IBMUS, Martin W Sachs/Watson/IBM@IBMUS
cc:   ebxml-tp@lists.ebxml.org, dan@vcheq.com
Subject:  RE: updated requirements specification



David,

Unfortunately, it's not as simple as you suggest, since other teams besides
TRP have created their own terminology.
In this case, using "party" in agreement with TRP means disagreement with
Reg/rep (and vice versa).  As noted in the F2F  minutes: "Scott pointed out
that party is the root of the Registry/repository team's role taxonomy, and
that not all of those roles are applicable to the type of agreements we are
specifying."  At this point, the solution requires reconciliation across
(at
least) three teams.

Tony Weida
Edifecs

> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Thursday, October 19, 2000 8:57 PM
> To: 'Scott Hinkelman/Austin/IBM'; Martin W Sachs/Watson/IBM
> Cc: Burdett, David; ebxml-tp@lists.ebxml.org; dan@vcheq.com
> Subject: RE: updated requirements specification
>
>
> Scott
>
> With your suggested change of definition of "Party" to "an entity
> such as a
> company, department, organization or individual." We are really
> beginning to
> go down a rat hole.
>
> The whole purpose of creating a set of definitions for TRP was to avoid
> precisely the debate we have just got into.
>
> I strongly suggest that: a) if we have a definition that has been used
and
> accepted by several parts of ebXML for a period of time then b)
> other teams
> should adopt it, otherwise we will be in endless, non-productive
> "definition
> churn".
>
> When new groups come along they really, really should try and build on
the
> work done by other groups and not unilaterally change definitions
> because of
> the huge confusion it causes.
>
> Regards
>
> David
>
> -----Original Message-----
> From: Scott Hinkelman/Austin/IBM [mailto:srh@us.ibm.com]
> Sent: Thursday, October 19, 2000 11:59 AM
> To: Martin W Sachs/Watson/IBM
> Cc: Burdett, David; ebxml-tp@lists.ebxml.org; dan@vcheq.com
> Subject: RE: updated requirements specification
>
>
> To add more to definitions/terminology since it is a current topic...
> Focusing at the top........
>
> >>>4.     Party. A Party is an entity such as a company, department,
> organization or individual that can generate, receive or relay Documents.
> 5.   Partner. A Partner is a Party that can engage in transactions with
> another Partner. <<<
>
> Concerning the highest notion, ...Party,
> I'm generally not thinking so specific about Party as above. In my mind,
I
> would stop at
> "Party: A Party is an entity such as a company, department,
> organization or individual."
>
> A Party is not ebXML specific.
>
> So,first we base common notions such as ebXMLIdentifiable
> (cumulative rule)
> for *anything* in ebXML that has identity.
>
> If you buy into this so far, and then push this thinking further,
> we then have InvolvedebXMLParty, which is also an
> ebXMLIdentifiable (You can not participate in ebXML without some
> identity). InvolvedebXMLParty then becomes the top notion in ebXML for
> "entities such as a company, department,organization or individuals".
>
> This allows ebXML to fit into other worlds that use plain old "Party".
> Then we further specialize to Partners, etc, beyond that.
>
> Over-Engineered, or too "pure" for what it is worth?
>
> PS:
> And like "Object", which should disappear ebXML,
> I would like the overloaded term "transaction" to go away also.
>
> Scott Hinkelman, Senior Software Engineer
> XML Industry Enablement
> IBM e-business Standards Strategy
> 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
> srh@us.ibm.com, Fax: 512-838-1074
>
>
>
> Martin W Sachs/Watson/IBM@IBMUS on 10/19/2000 12:21:32 PM
>
> To:   "Burdett, David" <david.burdett@commerceone.com>
> cc:   ebxml-tp@lists.ebxml.org, dan@vcheq.com
> Subject:  RE: updated requirements specification
>
>
>
>
> David,
>
> The appended contains some very good suggestions.
>
> Here are my replies.
>
> Regards,
> Marty
>
> (See attached file: TP Definitions MWS Resp.doc)
>
> ******************************************************************
> **********
> *********
>
>
> 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
> ******************************************************************
> **********
> *********
>
>
>
>
> "Burdett, David" <david.burdett@commerceone.com> on 10/18/2000 01:00:56
AM
>
> To:   Martin W Sachs/Watson/IBM@IBMUS, ebxml-tp@lists.ebxml.org
> cc:   dan@vcheq.com
> Subject:  RE: updated requirements specification
>
>
>
> I know that ...
> a) I raised the issue about the confusion in terminology between Party
and
> Partner, and
> b) I couldn't make the F2F to suggest that we stay with Party
> ... but the current requirements document is very wooly on definitions.
> Specifically  it says in items 3 and 4 ...
>
> >>>4.     Party. A Party is an entity such as a company, department,
> organization or individual that can generate, receive or relay Documents.
> 5.   Partner. A Partner is a Party that can engage in transactions with
> another Partner. <<<
>
> What is not defined anywhere as far as I can see is what is meant by
> "transactions". The word is used in the opening paragraph as in ...
>
> >>>a Trading Partner is an entity that engages in commercial transactions
> with other Trading Partners<<<
>
> One of the cardinal rules, IMO, of definitions is that they should be
> cumulative, i.e. you don't use a term until you have defined it. The
> current
> document is circular in that Collaborative Process uses CPA before we've
> defined it, yet CPA relies on a definition of Collaborative Protocol that
> depends on a definition of Collaborative Process.
>
> This means that the definitions should be more along the lines of the
> attached document.
>
> Thoughts?
>
> David
>
> -----Original Message-----
> From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
> Sent: Tuesday, October 17, 2000 2:39 PM
> To: ebxml-tp@lists.ebxml.org
> Cc: dan@vcheq.com
> Subject: updated requirements specification
>
>
> Attached is our partner-requirements specification, updated per the
> discussion at last weeks Face to Face meeting (described in the minutes).
> As previously mentioned, Daniel Ling will immediately convert the
> format to
> the official ebXML format and I will then begin the approval process.
>
> This does not cut off discussion but it does assure that we have this
> specification on the path to approval for the Tokyo meeting.  The results
> of discussion of this version will be applied to a later version.
>
> I have not marked the changes.  Last week's discussion resulted in many
> small changes and a few significant ones.  It needs to be
> reviewed in full.
> One particular change is that the term "Trading-Partner Agreement" is
> re-introduced per the request of Klaus Naujok. A Trading-Partner
Agreement
> includes a Collaboration Protocol Agreement and higher-level business
> information.
>
> Regards,
> Marty
>
> (See attached file: partner-requirements.doc)
>
> ******************************************************************
> **********
>
>
> *********
>
> 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
> ******************************************************************
> **********
>
>
> *********
>
>
>
>
>
>
>