Re: TA report for our con call tomorrow

[duane <duane@xmlglobal.com>]

Nagwa:

I apologize in advance for this long email.  Thank you for the
comments.  

In general:  I feel that the TA doc does contain some shortcomings
however, for most of these,  I think we should send it to the plenary
for a wider cross section of comments.  This isn't the final version
going out for a final vote.  It is a first draft for the first comment
period.  Accordingly, we feel it is necessary to solicit comments from
the plenary.

Some rebuttal to your comments (in line):

> 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

Each part contains an overview and a section labelled "Functional
Requirements".  In each of those we have attempted to define what the
components must facilitate without going too deep and stepping on the
toes of the Project team repsonsible for that area. Can you please
provide specific examples of where you se it not meeting your teams'
definition of "clearly defined" and "put in context"  	

> - lacks HIGH-LEVEL Use Cases for the operability of ebXML compliant
>   applications.

We were told that we should not be defining what an ebXML compliant
application should do.  If this is wrong,  can you please clarify this
with the STC.  I am happy to begin work on "Building an ebXML compliant
application" however,  we viewed this as something best done after all
the specs have been approved due to dependancies on those specs.

> - Lacks "scoping" the vertical efforts: what the BP should define and
>   why? How the TPA interacts with the BP and the TRP ? Etc.
We gave an example of a BP document and described its' functionality.
Again,  please give us specific feedback on what you forsee as a
shortcoming.

> - It over-steps its bounds by attempting to define conformance testing
>   which is not part of Architecture.
This was discussed by the STC.  I think we need to define it here. If
not here - where?  I am not attached to the outcome of that
conversation.   If it is decided that someone else whould do this - so
be it.  THis may be an issue better left to the plenary and the STC.  

> - Incomplete and contains several "... to be discussed later ...", "...
>   TBD ...", "... see section zzzz ..."
THe TRP and Reg Rep spec also contained these.   We want to solicit
comments from the plenary.  Some are also typos but hardly warrant the
spec from not being circulated.

> - It is too focused on RegRep at the expense of other issues. Even with
>   RegRep, is describes one solution instead of prescribing interfaces.
Don't the use cases describe the functionality neede from the
interfaces.  Our goal was not to do the interface work of all the
components,  jsut describe what must be facilitated by those specs.  If
our scope is going to be changed to address this,  so be it.  PLease let
us know your decision.

a
> - internal inconsistencies
>         - 3.1 "seven major component specifications"
>         - 5.0 "six major component specifications"
Noted - thanks ;-)

> - 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"
Refer to comment above.  

> - diagrams hard to understand
>         - Figure 1.0
I will personally take respnsibility for this.  We do intend to clean up
the existing diagrams and add more where appropriate.
 
> - don't mention vendors
>         - 6.3 "Biztalk"
Point well taken.   Will address.

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

We wish to solicit input from the plenary.  Again - if this was the
final spec - yes it should be with held pending the finishing of those
sections.  We have lots of work to do but feel it is better done in the
eyes of the plenary than by us behind closed doors.

> 
> It is also too long. should be a shorter doc with a few simple
> figures.  We should be showing high level architecture. 

This comment seems to be in constrast to your first two comments. 
Please provide specific examples where you see this as too detailed |
too short.

 >   a.. repeats the obvious (restates the charters of each group,
>       instead than asserting a mission for each of them)

The first section does this to provide context to readers of the
document.  We state that the audience includes "ebXML Project Teams".  
We wanted to rpovide a high level requirement for each of those before
stating the "Functional Requirements" for each team.

>   b.. too much focused on RegRep and, in addition, this focus tends
>       to describe a solution instead than prescribing interfaces
>        /usage-scenarios.

Noted.

>   c.. lacks a complete architecture where each of the parts (Registry,
>       Repository, BP, TPP, TPA, CC etc) are clearly DEFINED and put in
>        context

The first diagram provides this but the level of detail was kept very
abstract.  We can work on this for the next revision.

>   d.. lacks HIGH-LEVEL Use Cases for the operability of ebXML compliant
>       applications.
We have included vvery detailed use case scenarios in appendix "A". 
They are very specific.  We had more abstract use cases in the previous
version however, we received a lot of comments that they were not
specific enough.  YOu may be out on your own in this opinion.  THis may
be best left to the plenary to decide.

>   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
We haven;t defined user interfaces but can do if this is percieved as a
shortcoming.  We purposely decided to refrain from describing an "ebXML
application".  If you and others feel we should do this,  we will do it
but there are dependancies on the other specs for this.   

Can I suggest that the architecture team, after finishing the TA spec, 
maybe can focus its' energy on a "Building an ebXML compliant
Application" white paper?  That may be a better route to go than trying
to define a concrete User Interface when there is so much other work to
be done (expecially within BPM - modeling issues).

>   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
See comment above.

>   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)
"Defining a basic Interaction" is the work of BPM.  We have defined what
they must facilitate in their work but we are leaving the work to that
group and feel they have made some great progress lately.   

>   h.. Lacks "scoping" the vertical efforts: what the BP should define
> and
>       why?
Please clarify - I don't understand this comment.

 How the TPA interacts with the BP and the TRP ? etc.

I can place some stuff from the PPT from San Jose into the TA spec but
it will make it longer.

>   i.. Lacks a "global vision" of "how this is used in real life" !
THis is more of an implementation issue.  Please be more specific.

>   I mean, in real life things like accountability of a business process
> are
> fundamental, no one who seriously engage in something without this.

I totally agree but is it our teams' job to define this or BPM. 
Whatever is decided, we are open to it and will comply.

 > this is not in someway "architected", it will be implemented by the
tool
> 
> vendors in inconsistent ways...
WE have stated that the architecture consists of the seven ( I may be
wrong here) specification in unison.  This comment is also one of my
greatest concerns.  If we give the specs to ten different vendors,  they
should build ten version of the same product,  not ten different
products.  I don't know if TA can define an architecture for an ebXML
application at this point.  We really need to consider the "Building an
ebXML compliant Application" white paper approach.  THis may be
necessary.  UDDI made the "Programmers' API specification" which is a
very good idea. One of our goals is that we come up with an
implementable solution.  The question should be "Is the TA spec the
place to define this"?

>  It is too focused on
> RegRep at the expense of other issues. Even with RegRep, is describes
> one solution instead of prescribing interfaces.  
I would like to get comments from the REg Rep team to validate your
opinion.  If they feel we have overstepped our boundaries,  then we will
scale it back.  IMHO - everything that is in the spec was absolutely
necessary in respect to Reg Rep.  We pared it down quite a bit from
previous versions.   Let's get it to the plenary for a wider cross
section of comments.
> 
> 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.

I don't understand this comment.  It seems in complete contradiction to
your earlier comment that it doesn't of into enough details.  

THose are two mutually exlcusive comments.  Can you please be more
specific.

Thank you for the comments.  

Duane Nickull