Re: TA agenda Tokyo

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

Duane,

I agree with you that we have to get the the TA team and the QR team together first to resolve these issues,
and I think it will be a good idea if we have a Steering Committee meeting following that to discuss the results and get the project leads to involve.
but when you said:
 
      If the work they have done does not enable the mechanistic functionality of
      a cohesive architecture,  it is the groups work that must change, we cannot
     simply change the Architecture document to reduce the overall functionality of ebXML.

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

Duane Nickull wrote:

nagwa wrote:
>
> Duane,
>
> I also want to mention that the goal of their meeting is not only to discuss the
> comments from the QRT, it is also to get an agreement between all the project leads
> that this document is in-line with their specification. I suggest to include to the
> meeting agenda some time for each of the project team leaders to review their parts
> in the TA document.
>
> Nagwa
>>>>>>>>>>>>>>>>>>>>>>

Nagwa:

I think the correct correlation between TA and the other groups is that
the other groups efforts must facilitate the functionality specified by
the Architecture, otherwise all we have is a group of independent
projects which do not work together.  If the work they have done does
not enable the mechanistic functionality of a cohesive architecture,  it
is the groups work that must change, we cannot simply change the
Architecture document to reduce the overall functionality of ebXML.

That would not be acceptable to the world.

Having said that,  we also need to have the input from the teams for gap
analysis and overlap analysis (the latter being your groups' domain).

Many of the teams have already emailed us privately commenting that they
are very satisfied with the current document.  Others have comments
which need to be addressed and they will have an opportunity to talk to
us on the days following the QRT/TA Team meeting.  It is the QRT that is
giving us the most resistance right now so I feel that it is important
to get those issues resolved first, before we open up for further
comments.

Duane Nickull