TA report for our con call tomorrow

[nagwa <nagwa.abdelghfour@sun.com>]

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:

- lacks a complete Architecture where each of the parts are clearly
  defined and put in context
- lacks HIGH-LEVEL Use Cases for the operability of ebXML compliant
  applications.
- It does not show how the components are fit together and what they
  expose at their edges
- Lacks "scoping" the vertical efforts: what the BP should define and
  why? How the TPA interacts with the BP and the TRP ? Etc.
- It over-steps its bounds by attempting to define conformance testing
  which is not part of Architecture.
- Incomplete and contains several "... to be discussed later ...", "...
  TBD ...", "... see section zzzz ..."
- 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.