Re: Formal Protest from XMLGlobal

[Bob Sutor <rss@sutor.com>]

This was discussed today at the Steering Committee call.
The attending Executive Committee members (Klaus, Bill, 
and Bob) agreed that it is up to the RR project team to
decide what they want to say and use regarding a query
language. There was no disagreement from the Steering
Committee members present.

While XMLGlobal individuals may disagree with this (as
is their right, of course), the consensus of the project
team wins. Anyone who disagrees with the overall 
specification can raise their issues when the spec goes
to vote before the plenary.

Personal comment:

Query languages are religious issues with many people
and this should be understood when having discussions
about them. While the document discusses that other
languages will be monitored (and there are many), from
a marketing perspective we need to say that the work
of the W3C XML Query working group should be examined
for applicability when it is standardized and any future
revision of the RR work is undertaken.

Bob Sutor
ebXML Vice-Chair
IBM Director of e-business Standards Strategy



>Date: Wed, 27 Dec 2000 15:34:59 -0500
>From: David RR Webber <Gnosis_@compuserve.com>
>Subject: Formal Protest from XMLGlobal.
>Sender: David RR Webber <Gnosis_@compuserve.com>
>To: ebxml repository <ebxml-regrep@lists.ebxml.org>,
>        Martin Bryan <mtbryan@sgml.u-net.com>,
>        Klaus-Dieter Naujok <knaujok@home.com>

We would like to protest that the current drafts contains
exclusive references to use of OQL.

We would like this protest noted in a new section in the
document - Dissentions and Protests.

In Tokyo the syntax for ad hoc queries was discussed and
the decision was made that a decision matrix would be
created and that evaluation criteria would be tabulated
prior to any long term commitment on query syntax.

Sun staff made several assertions pertaining to OQL that
have subsequently been difficult to corroberate from
independent sources.

At the VERY LEAST the wording should be revised to
state that  - for the proposes of the PoC in Vancouver,
temporary use will be made of OQL syntax as a means
to demonstrate functional capability - but that this in
NO WAY represents a defacto decision to exclusively
use OQL.

Long term decisions on Query syntax should take
full account of W3C work in this area - and also the
requests from other ebXML working groups - such
as Core Components.

Respectfully,

DW.   VP Business Development XMLGlobal.

===================END FORWARDED MESSAGE===================
==================BEGIN FORWARDED MESSAGE==================
>From: "Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>
>To: "'David RR Webber '" <Gnosis_@compuserve.com>,
>        "'ebxml repository '"
>	 <ebxml-regrep@lists.ebxml.org>,
>        "'Martin Bryan '" <mtbryan@sgml.u-net.com>,
>        "'Klaus-Dieter Naujok '" <knaujok@home.com>
>Subject: RE: Formal Protest from XMLGlobal.
>Date: Wed, 27 Dec 2000 16:08:59 -0600

David, your protest is acknowledged.

RR will anticipate the response from the QRT, which may include
your
concerns.  We must follow due process at this point, due to
critical
timeframes.  this is not out for public review.

My opinion going into this was that a single canonical query
syntax
(whatever the syntax) is a fundamental requirement for query
standardization, following the lead from OMG in their Query
Services
specification.  Mapping various query syntaxes (Quilt, SQL 92) to
this
cananical form is the most efficient means.  At this time OQL is
specified
as this cananical form similar to the OMG specification.

I also believe in your viewpoint that this comparision should be
documented.
Sorry to bring this up, but you were the one that committed to
produce this
document in the Tokyo meeting.  RR is currently bandwidth
constrained, as
are many of the other project teams.

RR would be interested in these stats, hopefully including a
matrix of query
syntax capabilities and vendor product implementations.  However,
tasking
the current team (who is working very hard) to deliver this
documentation at
such a critical point in time, would cripple our ability to
produce ANY RR
specifications on-time.  While you may not agree, I think that
"on-time"
currently out weighs the immediate concern.  Perhaps the review
cycle will
allow us to document your request, once we finalize EXACTLY what
is needed.

Please help me out regarding the Core Component request.  Was it a
"requirements" document that was emailed directly to me, that I
forwarded it
to our list?  The posting got zero replies, so I brought it up to
the StC
four weeks ago.  We (RR/CC) needs to follow up with a
teleconference to
either discuss this version, or perhaps a version that includes
more
background information and examples.  Is this information also in
the ebXML
Requirements specification?

Thank you for your concern, and I hope you are having a great
holiday!
Scott