RE: TA agenda Tokyo

[Krishna Sankar <ksankar@cisco.com>]

Brian et al,

	Here is my picture about the positioning of the architecture and the other
groups in terms of flow hierarchy. Of course, all the groups motivate, help
and drive each other. There is no strict hierarchy and there shouldn't be,
as this is a voluntary standard. IMHO, our mission is to deliver the six or
so specifications, collectively.

	cheers

-----Original Message-----
From: Brian Eisenberg [mailto:BrianE@DataChannel.com]
Sent: Monday, October 30, 2000 5:24 PM
To: ebxml-architecture@lists.ebxml.org
Cc: 'Matthew MacKenzie'; nagwa
Subject: RE: TA agenda Tokyo


>>>>>>>>>>

  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.

>>>>>>>>>I tend to agree with Matt's statement in that it is critical that
the working groups and TA team make sure that their work is in alignment
with the TA spec. At the same time, the very nature of the process in which
ebXML standards/technologies/software are developed, make it inherently
difficult to
keep things in alignment. We have witnessed this difficulty first hand in
our effort to create a unified ebXML glossary (which we are close to
finishing), and also in some of the intense discussions on the ebXML lists
(e.g. partner vs. party terminology discussion on the TA list).

I think that Matt is right in that the TA spec may benefit by drawing upon
the more "mature" specifications (e.g. Messaging Services) to move into
alignment, but not at the expense of becoming puppets to sub groups that are
still evolving. An important goal of the TA spec is to provide that common
unified vision of ebXML as a whole. Having a glossary that all teams can use
is a step in the right direction. Having an architecture document that
represents ebXML and helps guide the direction and focus of the less
"mature" specifications is what we're trying to achieve. That said, we (the
TA team) have been walking on a tightrope to try our best at setting forth
some architectural guidelines, while at the same time being responsive to
specific input from project teams when potential misalignments are noted.

To move forward in a common, unified manner, it will be essential that the
TA team (by way of direct liaison-project team interactions) work  closely
with each team to make sure that there are no misunderstandings or
misalignment. The more we communicate across the entire ebXML community, the
closer we can move into alignment. I firmly believe that we can accomplish
this during the Tokyo meeting.

Regards,

Brian Eisenberg

ebxmlarch1.jpg