RE: latest Version; Chap16 Revision 2

["Burdett, David" <david.burdett@commerceone.com>]

I understand your view that business and eCommerce involves "relationships"
and "partnerships". However I think we need to develop technology (and I've
already provided use cases) that supports the exchange of messages
**before** the relationship or partnership has been set up. Hence my
preference the more general term of "party".

David
PS This thread is getting ridiculously long. I promise that after this I
will not try and respond to any more emails ... otherwise I think we should
call a party/partner "herman" so that we stop debating. Actually - resolving
this at the F2F is probably the best way forward.

-----Original Message-----
From: Scott Hinkelman/Austin/IBM [mailto:srh@us.ibm.com]
Sent: Thursday, October 19, 2000 10:41 AM
To: Burdett, David
Cc: Martin W Sachs/Watson/IBM; Tony Weida; Brian Eisenberg;
ebxml-architecture@lists.ebxml.org; 'Klaus-Dieter Naujok '; 'Bruce Peat
'; 'Jeff Suttor '; 'Duane Nickull '; 'David Webber ';
ebxml-tp@lists.ebxml.org
Subject: RE: latest Version; Chap16 Revision 2


I guess my view fundamentally comes from my experience that everytime I get
involved with something,
inside my company or outside, every effort has a Party. Now is that good or
bad? I don't know for sure,
but there just seems to be something more specific here in ebXML
considering what it is about that
makes me think to avoid the ultimate generalized term of Party, and use
something thats seems there
is a relationship.

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



"Burdett, David" <david.burdett@commerceone.com> on 10/18/2000 10:31:12 AM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   Tony Weida <TonyW@EDIFECS.COM>, Scott Hinkelman/Austin/IBM@IBMUS,
      Brian Eisenberg <BrianE@DataChannel.com>,
      ebxml-architecture@lists.ebxml.org, "'Klaus-Dieter Naujok '"
      <knaujok@pacbell.net>, "'Bruce Peat '" <bpeat@processsolutions.com>,
      "'Jeff Suttor '" <jeff.suttor@sun.com>, "'Duane Nickull '"
      <duane@xmlglobal.com>, "'David Webber '" <Gnosis_@compuserve.com>,
      ebxml-tp@lists.ebxml.org
Subject:  RE: latest Version; Chap16 Revision 2



Marty

I don't doubt there was agreement within the TP group. We have already been
through one protracted debate over party vs partner and concluded on the
list (not just a meeting of particularly interested parties) that the more
generally applicable term was Party and not Partner.

If the TP group continues to use Partner then both Core Components and TRP
will have to change or we will have multipe definitions.

Although Partner is actually a reasonable term is there anything actually
WRONG with using Party. I also accept that Klaus may prefer Party but
should
Klaus's preference take precedence over a topic that was debated - and
agreed - on the list.

I'm also not sure that Klaus is fully aware of the earlier debate. If Klaus
reviews the previous email thread and says words along the lines of "I have
reviewed the email correspondence on the debate over whether to use Party
or
Partner and, even though there was a previous decision on the list to use
the term Party, I have decided that we should use Partner and recognize
that
the Core Components and TRP groups must change the work they have been
doing
for the last 8 months" then I will accept it.

Finally TP has only been going since August. It should not, IMO, dictate to
the rest of ebXML the terminology to be used.

Best wishes to everyone - I do recognize that everyone is just trying to do
it "right" ;)

David



-----Original Message-----
From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, October 18, 2000 7:20 AM
To: Burdett, David
Cc: Tony Weida; Scott Hinkelman/Austin/IBM; Brian Eisenberg;
ebxml-architecture@lists.ebxml.org; 'Klaus-Dieter Naujok '; 'Bruce Peat
'; 'Jeff Suttor '; 'Duane Nickull '; 'David Webber ';
ebxml-tp@lists.ebxml.org
Subject: RE: latest Version; Chap16 Revision 2



Terminology definitely has to be consistent across ebXML.  The change from
Party to Partner reflected a strong consensus in the group present at the
Face to Face, which included several TRP people besides myself.

We can, of course, revisit the discussion but please first look at what is
actually in the Requirements document that I posted last night.

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

*********



"Burdett, David" <david.burdett@commerceone.com> on 10/17/2000 11:13:14 PM

To:   Tony Weida <TonyW@EDIFECS.COM>, Scott Hinkelman/Austin/IBM@IBMUS,
      Brian Eisenberg <BrianE@DataChannel.com>,
      ebxml-architecture@lists.ebxml.org, "'Klaus-Dieter Naujok '"
      <knaujok@pacbell.net>, "'Bruce Peat '" <bpeat@processsolutions.com>,
      "'Jeff Suttor '" <jeff.suttor@sun.com>, "'Duane Nickull '"
      <duane@xmlglobal.com>, "'David Webber '" <Gnosis_@compuserve.com>,
      ebxml-tp@lists.ebxml.org
cc:
Subject:  RE: latest Version; Chap16 Revision 2



Tony

There was a lot of discussion earlier on the list about the use of the term
"partner" rather than "party" and there was an original decision to move to
using "party".

The reason was that, in TRP, "party" rather than "partner" or "trading
partner" was preferred since the protocols and specs produced by TRP should
be usable in a "non-business" as well as a "business" context.

I think this is, and will continue to be true. Therefore, we need to think
whether or not we need to use terms consistently between TRP and TP.

Thoughts?

Regards

David

-----Original Message-----
From: Tony Weida [mailto:TonyW@EDIFECS.COM]
Sent: Monday, October 16, 2000 5:22 AM
To: Scott Hinkelman/Austin/IBM; Brian Eisenberg;
ebxml-architecture@lists.ebxml.org; 'Klaus-Dieter Naujok '; 'Bruce Peat
'; 'Jeff Suttor '; 'Duane Nickull '; 'David Webber ';
ebxml-tp@lists.ebxml.org
Subject: RE: latest Version; Chap16 Revision 2


Scott,

This is an excellent write-up that I believe very accurately reflects the
deliberations of the TP team at our face to face meeting last week.  Two
minor points:

- A couple reference are made to parties rather than partners (the agreed
term).

- In the last diagram, I believe that one of the "same semantics" lines
should connect BP XML with BP UML, rather the UML modeling tool.  The one
between the UML and XML modeling tools is correct.

Thanks,
Tony Weida
Edifecs

> -----Original Message-----
> From: Scott Hinkelman/Austin/IBM [mailto:srh@us.ibm.com]
> Sent: Sunday, October 15, 2000 2:14 PM
> To: Brian Eisenberg; 'ebxml-architecture@lists.ebxml.org ';
> 'Klaus-Dieter Naujok '; 'Bruce Peat '; 'Jeff Suttor '; 'Duane Nickull ';
> 'David Webber '; ebxml-tp@lists.ebxml.org
> Subject: latest Version; Chap16 Revision 2
>
>
> My prvious message:
> >Attached is rework 1 of Chapter 16 on TPA. Our TPA F2F meeting
> resulted in
> >a more clear across the board understanding of how it fits. We have also
> >made specific terminology adjustments, and are now formally
> distinguishing
> >between the profile function and agreement function.
>
> >Concerning the terminology and rest of the document,
> >"TPA" are now cast as as a larger scope that what ebXML is addressing,
so
> >we only may need to adjust the usage of "TPA" elsewhere to indicate
> >something of the nature of... the context of support for TPA's in ebXML.
>
> >This is incomplete and I will send another before Monday, but given the
> >urgency of the calendar, here is what it is as of now.
>
>
> I am attaching draft 2 of the TPA section.
> I am copying the Arch and TP lists and will not edit more until
> feedback/discussion is recieved.
>
> I have not yet digested the latest Arch document but
> my initial reaction is that this is significantly better than what we
had.
>
> Some initial comments. I will have more.
>
> 1) Intro and Chap 9: I am concerned that too much reference to EDI
> is present  and may give the impression that ebXML is so closely tied to
> EDI that
> none of it can be used out of that context. Not that this
> information/motivation is
> wrong, but I question if the backgroud information should be in an
> architecture
> document. Most technical architects would not expect it. It seems much of
> the
> intro would make good content for some sort of executive overview
> rather than in the TA.
> 2) All of the references to "Business Objects", or Objects in general
> should be
> removed. These terms have very well understood concepts within software
> architecture
> and development communities, and especially in my company. ebXML is not
> about Objects.
> 3) Figure 1 around line 204 step 4 and the narrative would be
> better worded
> not to include
> "implementation details", and perhaps "advertise/claim support
> for Business
> Collaborations and matching technology capabilities" or some such.
> 4) Line 226: This does not seem right "is then informed". It might be
more
> clear to
> indicated query of Partners claiming support for specific Business
> Collaborations/
> Commercial Transactions.
> 5) Terminology: line 260 and perhaps others, I suggest we narrow to two
> basic terms
> for involvement: Party and Partner, where Party includes everyone
> (like the
> RegRep
> RA, etc) but Partner is specific to those that engage in business. Drop
> Participant.
> 6) Why are we using the term "Lexicon" ? If we are simply refering to
Core
> Components
> lets drop it. I still don't get what it means.
> 7) We should generally stop using the word Core Components. "Component"
is
> one of the
> most overlaoded terms in I/T and has cause much confusion as to what it
> means in
> ebXML. I suggest renaming Core Components to Core Business Structures,
the
> sooner the better. They are data structures.
>
> (See attached file:
> ebXML_TA_v0.8.72i_Chap16_Hinkelman_PartialRevision2.doc)
>
>
> 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
>
>