RE: TA agenda Tokyo

["Cunningham, Robert" <CunninghamR@MTMC.ARMY.MIL>]

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