RE: latest Version; Chap16 Revision 2

["Petit, John" <jpetit@kpmg.com>]

Very good work Scott!

-----Original Message-----
From: Scott Hinkelman/Austin/IBM [mailto:srh@us.ibm.com]
Sent: Sunday, October 15, 2000 2:10 PM
To: Brian Eisenberg; 'ebxml-architecture@lists.ebxml.org ';
'Klaus-Dieter Naujok '; 'Bruce Peat '; 'Jeff Suttor '; 'Duane Nickull ';
'David Webber '
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
*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. 

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.         
*****************************************************************************