Re: TA agenda Tokyo

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

Cunningham,

I completely agree with you,
see you in Tokyo,

Best Regards,
Nagwa

"Cunningham, Robert" wrote:

> Nagwa,
>
>         May I submit, now that the TA is out on the web for review, the
> individual members of the ebXML plenary and each of the project teams review
> it, submit their comments so that we concentrate, in Tokyo, on ensuring that
> the TA actually does describe the over all technical architecture for which
> each of the project team documents support.
>
>         We may find that the issues between the TA and the project teams are
> very minor and can be corrected with little effort.
>
>         Duane and the TA project team are only trying to ensure that the
> final pieces to the puzzle actually fit together and are acceptable to the
> ebXML members.
>
> Respectfully,
>
> Bob Cunningham
> Military Traffic Management Command
> Alexandria, VA.
>
> -----Original Message-----
> From: nagwa [mailto:nagwa.abdelghfour@sun.com]
> Sent: Monday, October 30, 2000 7:42 PM
> To: Duane Nickull
> Cc: Murray Maloney; ebxml-architecture@lists.ebxml.org; 'ebXML
> Coordination'
> Subject: Re: TA agenda Tokyo
>
> 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