RE: TA report for our con call tomorrow

[Clive Darling <clive.darling@attglobal.net>]

Nagwa,
I certainly agree with your main points here. However, since disapproval
is something not to be taken lightly, I would like to question whether a
couple of the points are real issues that we can't live with, or at least
make alternative suggestions. I've given your bullets numbers, with my
remarks following >
 5. It over-steps its bounds by attempting to define conformance testing
    which is not part of Architecture.
  > It is actually quite useful to state somewhere what it means to be
  > ebXML conformant. Rather than just saying 'not here' can we recommend
  > where the general concept of conformance should be defined.

 6. Incomplete and contains several "... to be discussed later ...", "...
    TBD ...", "... see section zzzz ..."
  > In the case of TRP we passed it with sections, e.g. security 'missing'.
  > Are these real disapproval points?

 7. It is too focused on RegRep at the expense of other issues. Even with
    RegRep, is describes one solution instead of prescribing interfaces.
  > I agree - there is uneven treatment, but maybe we should be specific
  > about what is unnecessarily written ablout RegRep, and what is missing
  > about the others.
  > I think your second sentence is making a different point from the first,
  > and is covering the same ground as your point 3?

 > Finally a couple of typos in part 2...
 > a) Second to last paragraph, beginning "specific file names"
 > b) The very last half-paragraph is more or a repeat.

Sorry I won't be able to join you tonight.
Regards, Clive.

Clive Darling
Business Development, TIE Holding NV
Tel: +31 20 658 9277  Fax: +31 20 658 9901

-----Original Message-----
From: nagwa [mailto:nagwa.abdelghfour@sun.com]
Sent: 19 September 2000 00:27
To: 'ebXML Coordination'
Subject: TA report for our con call tomorrow


Hi All,

I put together this report about the TA. The first part are the reasons
Why this
documents shouldn't approve to go to public, and in the second part are
the
details which I gathered the first part from . I thought it is important
to
provide the  executive committee by a summery attached to the detailed
report.
Please review it and let us discuss it during our tomorrow con call,

Nagwa


Part 1.
=======
Why we shouldn't approve this document for public review:

1. lacks a complete Architecture where each of the parts are clearly
   defined and put in context
2. lacks HIGH-LEVEL Use Cases for the operability of ebXML compliant
   applications.
3. It does not show how the components are fit together and what they
   expose at their edges
4. Lacks "scoping" the vertical efforts: what the BP should define and
   why? How the TPA interacts with the BP and the TRP ? Etc.
5. It over-steps its bounds by attempting to define conformance testing
   which is not part of Architecture.
6. Incomplete and contains several "... to be discussed later ...", "...
   TBD ...", "... see section zzzz ..."
7. It is too focused on RegRep at the expense of other issues. Even with
   RegRep, is describes one solution instead of prescribing interfaces.



Part 2.
=======

- some sections are more requirement and implementation oriented
v. architectural
        - 6.2 Use case list and descriptions
        - 6.4 Run Time Overview
        - "7.2 Functional Requirements"
        - "8.2 Business Process Documents Requirements"
        - "8.3  Business process Modeling Functional Requirements"
        - "9.2 Core Component Functional Requirements"
        - "9.3 Common Business Object Functional Requirements"
        - 10.1 "define the minimal functional requirements which a
          Registry/Repository"
        - 10.4 use cases
        - "10.5.3 RA Requirements"
        - "10.9 Registry and Repository Security Requirements"
        - "11.0 Messaging and Transport Requirements"
        - 11.1 "This section specifically deals with the function
          requirements"
        - APPENDIX "A" use cases

- contains many implementation details
        - UC122 "ebXMLind.xml" file
        - 6.4(3) "utilize a special valid xml file named ebXMLind.xml"
        - 6.4(4) "parse the special file named ebXMLind.xml"
        - 6.4(6) "this SHALL be accomplished by utilizing a fixed
          attribute value for each XML"
        - 10. 10 "l.GUID SHALL be built using a combination of URN and
          a CDATA suffix that SHALL not exceed 8 bytes in length"

- internal inconsistencies
        - 3.1 "seven major component specifications"
        - 5.0 "six major component specifications"

- conformance testing is not part of Architecture
        - 5.0(1) "a set of conformance tests"
        - 6.1 "series of Conformant tests"
        - "12.0 ebXML Conformance and Testing"

- diagrams hard to understand
        - Figure 1.0

- don't mention vendors
        - 6.3 "Biztalk"

- document not complete
        - 6.3 "Note: SME scenarios to be discussed later."
        - 10.8.2 "SME's may not be using this model. SME integration
          will be discussed later."
        - 11.2 "The concrete realization of this abstract interface
          are yet TBD"
        - 11.2 "see section zzz for TPA"
        - 11.5(d) "d)defined in sections X.Y ? of this document"

It is also too long. should be a shorter doc with a few simple
figures.  We should be showing high level architecture.  Could we
focus on just showing the components, how they fit together and what
they expose at their edges?

---------------------------------------------------------------------

  a.. repeats the obvious (restates the charters of each group,
      instead than asserting a mission for each of them)
  b.. too much focused on RegRep and, in addition, this focus tends
      to describe a solution instead than prescribing interfaces
       /usage-scenarios.
  c.. lacks a complete architecture where each of the parts (Registry,
      Repository, BP, TPP, TPA, CC etc) are clearly DEFINED and put in
       context
  d.. lacks HIGH-LEVEL Use Cases for the operability of ebXML compliant
      applications.
  e.. lacks the "User Point of View", i.e. lacks presenting the
      Architecture in a way that a User can find its own business case
  f.. Lacks the "vendors Point of View", i.e. lacks presenting the
      Architecture in a way that a Vendor can find the possibility to
      define its own tool implementation
  g.. Lacks a "Roadmap", i.e. lacks presenting a path from how a Company

      defines a basic interaction to how the same Company can
      participate/establish a broader interaction (supply chain,
      market place, etc)
  h.. Lacks "scoping" the vertical efforts: what the BP should define
and
      why? How the TPA interacts with the BP and the TRP ? etc.
  i.. Lacks a "global vision" of "how this is used in real life" !

  I mean, in real life things like accountability of a business process
are
fundamental, no one who seriously engage in something without this. And
if
this is not in someway "architected", it will be implemented by the tool

vendors in inconsistent ways...

  This is quite a tricky thing. Given the complete distributed nature of
an
ebXML Business Process, what would it mean granting accountability and
manageability of a BP which spans organization boundaries?
  Again, if we are simply targetting one-to-one exchanges, probably what
I
am saying is "philosophy and pure speculation". But if we want to
support
Transactions across enterprises, than the thing is different.


specific file names and byte lengths for implementations.  It
sometimes focuses on specific details like calling out the vendor name
"Biztalk" in one of the diagrams and then just repeats the charters of
each of the other groups for their section.  It is too focused on
RegRep at the expense of other issues. Even with RegRep, is describes
one solution instead of prescribing interfaces.  It over-steps its
bounds by attempting to define conformance testing which is not part
of Architecture. The TA document contains figures that are hard to
understand.

The TA document is incomplete and contains several "... to be
discussed later ...", "... TBD ...", "... see section zzzz ..."  It
lacks a complete Architecture where each of the parts are clearly
defined and put in context.  It is also too long. It should be a
shorter document with a few simple figures.  It should be showing high
level architecture.  It should focus on just showing the components,
how they fit together and what they expose at their edges.