Tr: Comments on TA spec v1.0 - LAST CALL for public comments

["agrangard@nycall.com" <anders.grangard@edifrance.org>]

----- Original Message -----
From: Karsten Riemer - Sun IR Development <kriemer@volcano.East.Sun.COM>
To: <BrianE@DataChannel.com>; <anders.grangard@edifrance.org>
Cc: <kriemer@volcano.East.Sun.COM>
Sent: Monday, January 29, 2001 3:37 AM
Subject: Comments on TA spec v1.0 - LAST CALL for public comments


> Anders or Brian, please forward to TA team, since I cannot send to that
list.
>
> To the TA team, here are my comments on TA spec v1.0.
>
> In general this document has come a long way since its first state,
> I appreciate all the hard work that has been done.
>
> I divide my issues into two groups, showstoppers and editorial.
> Showstopper means I cannot vote YES to approve TA spec v1.0. unless they
are
> addressed. Editorial means I would like to have them addressed, but would
vote
> YES even if they were not.
>
> Showstoppers:
>
> Section 7 is not about a reference model, it is about the UMM. It could be
> removed entirely. The concepts of BOV and FSV and the list of artifacts in
> figure 3 relate only to UMM. You do not need to know anything about BOV
and
> FSV in order to understand the ebXML architecture, nor to be able to
implement
> ebXML. If the section is kept in any form, it MUST be titled "ebXML
> recommmended methodology".
>
> Line 299: Word reference model should be changed to methodology. ebXML
does
> not have a reference model or reference architecture, or if it does
someone
> needs to tell us what it is, and we need to make a normative reference to
it.
>
> Line 301: ISO 14662 is NOT the reference model or reference architecture
for
> ebXML, whereas it may be for UMM.
>
> Section 8 adds more confusion than value. Remove entire section. It
doesn't
> provide any new information that is not covered in section 6 or 7, but
> introduces the same information in a different way that makes users wonder
if
> they are looking at the same or something different. The word "phase" is
> confusing.
>
> All references to Business Object need to be changed to the term agreed
upon
> by executives in Tokyo, namely "Business Information Object" (or any
> subsequent executive override of that term that I may not be aware of).
Lines:
> 385, 387, 721, 799, 1014,   Figure 12, and probably more places
>
> All references to "object classes" should be removed, changed, or
qualified to
> be UMM related only. Lines: 313, 319,  and probably more places
>
> Line 613: drop "objects and"
>
>
> Editorial:
>
> Drop capitalization of MAY, SHOULD, etc. In many cases re-phrase to avoid
> those words.
>
> If any part of section 7 is kept: lines 323-348 add more confusion than
value.
> Remove entire block of lines.
>
> If section 7 is dropped, Figure 4 in section 7 should be moved to section
6 as
> an illustration of how ebXML architectural components satify the scenario
and
> bullets 1-7 in lines 237-258
>
> If section 8 is kept: Figure 6 list of registry content is wrong and
> inconsistent with other diagrams and text. Also, Figure 6 shows an odd
> triangle interaction that I do not understand.
>
> section 9.2.4: drop section altogether or make the picture illustrate the
text
> which talks about context
>
> Line 671 and line 704: Replace "Metadata" with "Information Model" or
> "Business Document Definition"
>
> Line 674: could be continued by line 677 as an example of metadata
>
> Line 692: drop sentence starting with "Accordingly". Or if you keep it
must
> correct that CPA supports more than the business transactional layer, it
> supports the collaboration layer as well.
>
> Line 513: I believe a party can register any number of profiles, not just
one.
>
> Line 604: drop sentence starting "The sequence..."
>
> Line 606: use consistent language, what is a Business Information
Component?
>
> Figure 11: needs updating to stay consistent with same figure in Bp Spec
> Schema doc, as recommended by QR.
>
> Line 226: Replace "conceptual model" with "possible scenario"
>
> Line 760: what technical needs does a core component capture?
>
> Line 229: Replace "System Component" with "Architecture Component"
>
> Line 776 and 778: Replace "Business Process" with "Business Document"
>
> Figure 14: put elipses (...) after CORBA to show that list is not
exhaustive
> nor normative.
>
> Line 878 and 881: what does published mean?
>
> Comment to QR comment about line 397-398: No, we are not talking about
> metamodels. All business processes that are used to drive CPA, and
> subsequently to configure message exchange must be in XML. Other models
that
> are used for related modeling work are stored in XMI.
>
> Line 1143: A CPA does not have legal terms and conditions, that is why we
are
> not using the word trading partner agreement.
>
> Line 1151, 1153, 1155, 1211, 1213, 1215, 1309, 1311, 1313 (and maybe other
> places): replace "granting" with "ensuring"
>
>
>
> Thanks for listening,
>
> -karsten
>
>
> ---------------------------------------------------
> Karsten Riemer,
> Director, Information Architecture,
> Enterprise Management Architecture Group
> Sun Microsystems Inc.,
> MailStop UBUR03-313
> 1 Network Drive,
> Burlington, MA 01803-0903
>
> ph. 781-442-2679
> fax 781-442-1599
> e-mail karsten.riemer@sun.com
>