RE: TA agenda Tokyo

[Matthew MacKenzie <matt@xmlglobal.com>]

Nagwa,

  What you state makes no sense.  The architecture document was commissoned
at the
same time as the other documents, and is the document which really has the
most
ground to cover.  Using your logic, it was a predetermined fact that the TA
spec
would not be complete before the more tightly scoped special interest groups
returned
with their specifications.

  What needs to happen is the other groups, such as TRP, REGREP, BP/CC,
etceteras
must work with the TA group to align their specifications with what the TA
group
has done.  Since the TA specification is very young, it stands to reason
that
the more developed specifications of the sub groups would influence the TA
document's
evolution, but it should not become a puppet of those sub groups as doing so
would
be a statement of failure of the whole ebXML effort as a whole, that common
sense protocol
was not followed.

my $0.05

--
Matthew MacKenzie
VP Research & Development
XML Global Technologies, Inc.

-----Original Message-----
From: nagwa [mailto:nagwa.abdelghfour@sun.com]
Sent: October 30, 2000 4: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