Re: TA agenda Tokyo

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

Duane,

The TA document suppose be the (road map) to what is being develop in the
specs the working groups spend 12 month working on, the TA doc suppose to
define the interfaces and interactions between all the components, and if
these working group  are developing their spec according to the scope and
the functionality of exbxml requirements doc, and there are no overlaps or
problems with the integration between the components, they not suppose to
change just because the TA document has larger scope or different
functionality. I know it is not how it should be done, and the TA document
suppose to be the first document and provide the road map for other specs to
follow, but you know as every one else in ebxml know, it is too late for
that.

Nagwa


Duane Nickull wrote:

> 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