Re: TA agenda Tokyo

[Duane Nickull <duane@xmlglobal.com>]

nagwa wrote: 
> Is this means that if the any of working groups have a different
> vision of the functionality and Scope of ebxml,  than  what the TA
> document is presenting, the working group should change to meet the
> scope and functionality of the TA document, or I misunderstood you, if
> this is what you meant, I am afraid to say I don't agree with you, it
> is too late to do that, I believe the TA document now suppose to be
> driven by the working groups specs, the only time the working group
> need to change if there are overlaps, integration problem between the
> components, or they are presenting functionality out of ebxml scope.
>>>>>>>>>>>>>>>>>.

Nagwa:

The Architecture of ANY system ensures that the pieces fit together and
all the components work together for a common functionality.  I can't
even believe you would suggest the alternative.

Accordingly to most modern thinking, Architecture describes interfaces,
constraints, interactions and outlines components that interoperate to
make a functional system.  

What if the TPA doesn't allow for business partners to trade information
back and forth?  What if TRP can't deliver messages with an XML UTF-8
payload?  These things have to be done or ebXML won't work.  If you
suggest even for a moment that we simply modify the TA to support
whatever it is the others group shave decided,  who's responsibility is
it to make sure that ebXML actually functions?

The TA Team has (along with significant contributions by many other
teams) spent countless hours ensuring we align with the Requirements
Group.  It was explained that the TA document will be the next document
to be approved back in Belgium.  

The Architecture is a roadmap to show what interfaces the other
components must supply in order to be functional as a whole.  

If your solution is to just let all the other groups develop whatever
they want and have TA document it, it really paves the way for anarchy
among ebXML groups.

Duane