OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: TA Spec for release to the plenary

Folks - 

We're not going to solve anything by continuing to exchange unpleasant
emails. Lets take a breather from the current threads bouncing around on the
mailing list. At this point, I think there are several issues that need to
be addressed before any further action is taken:

1. We've established that there are some flaws and general confusion
surrounding the Specification Approval Process
(http://lists.ebxml.org/archives/ebxml-coord/200010/doc00009.doc) and the
role of the Quality Review Team in this process. These issues need to be
addressed by the Executives and the Steering Committee. 

That said, I think there is some confusion over what it means to approve a
specification. The Spec Approval Process document says nothing releasing a
specification for "public review". The document states that:

-16	Team submits team-approved specification to Quality Review Team
-15	Quality Review Team returns review comments.  Team processes
comments submitted by Quality Review Team
-14	Team submits team-approved specification, addressing QRT comments,
to the ***full ebXML Work Group*** for first comment period.

In the earlier email exchange, Tim McGrath stated that:

"Whilst it may be Duane has a point on a technicality, the real question is
whether the TA Specification is suitable for public review?

The QR team believe it is not.  However, we do believe it requires input
from the
broader ebXML community and have proposed the Steering Committee as the best
means of achieving this.  We all agree that our objective is to get the TA
specification suitable for voting at the Vancouver plenary.
a. there is a difference between putting a document in the public eye and
input from the ebXML community.  it is kind of self-evident but the former
opens the ebXML architecture to criticism from outside, which may not be
productive at this stage, especially if it does not encapsulate the full
ebXML 'vision'." 

Again, the Spec Approval Process document says nothing about the difference
between "putting a document in the public eye and seeking input from the
ebXML community."

If the QR team firmly believes that the spec requires input from the broader
ebXML community (as Tim mentions above), then it should have APPROVED the
spec  for a first comment period (-15 above). 


2. The comments collected by the QR team
(http://lists.ebxml.org/archives/ebxml-coord/200010/msg00041.html) are very
detailed and in many cases reflect personal opinions, rather than a broader
consensus. These comments include many "I would..." and "In my opinion..."

***Please keep in mind that I'm not discounting these comments, as I do
agree with some of them. 

My point here is that these comments were made by a select group
individuals, and as such, may not be representative of the sentiment of the
broader ebXML community. This is why it is IMPORTANT to get the document out
for review by the entire ebXML community. 

Many of the issues raised in the Quality Review summary document
(http://lists.ebxml.org/archives/ebxml-coord/200010/doc00011.doc) are in
response to specific sections and are in some cases, contradictory in nature
(Duane's email addressed these issues). 

Given that the document is still a "DRAFT" it will be relatively easy to
address the comments that the QR team made and to make the appropriate
changes to the spec to satisfy the concerns raised by the QR team. However,
before we make any changes, we firmly believe that it is IMPERATIVE to get
feedback and comments from the broader ebXML community. This will allow us
to gain consensus about what needs to be changed/modified in the spec,
taking into account the comments from the QR team, as well as any issues
raised by the broader ebXML community. 

I think it's important to keep in mind what this process is all about -
making sure that the specification is accurate and reflects the overall
ebXML architecture. This can only be accomplished through peer review by ALL
ebXML participants. I suggest that the Executives and Steering Committee
seriously consider approving the document for release to the broader ebXML
community for a first comment period. 


Brian Eisenberg

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC