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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-regrep message

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

Subject: Re: vOTE CALL: RE: Counter Proposal Paper Draft 0.9

My Vote: NO

IMHO, The proposal does not show how the requirements identified in:


are being addressed. Nor does it state reasons why those requirements are

I had considerable difficulty understanding the proposed approach. It seems
very vague. It also seems to be essentially the same as focused queries if I
am not mistaken. I find that the definitions of ad hoc query and constrained
ad hoc query that I had made in link cited above are clearer. I believe this
paper is incorrectly calling the proposed approach ad hoc. It is not even
constrained ad hoc IMHO according to my understanding of the definition.

I am very dubious about the following statement in the proposal that suggests
adding to our specs language that encourages variations in implementations.

>>"To further support this, the ad hoc query API prescribes three categories
of methods,
>>required, preferred, and specific."

The above will be an inpleroperability nightmare.

>>"While at the same time offering a more open value model typical of ad hoc
querying, where the exact query >>content is provided by a XML structure
(similar to that provided by the API of UDDI methods)."

UDDI provides a fixed set of focused queries. As I said before this approach
suffers from a combinatorial explosion and maintenance nightmare problem.  I
would not hold UDDI as our guiding light or beacon. They have set a different
set of requirements as their target.

>>"The overall problem appears to be somewhat intractable, since an open ad
hoc query language is a holy grail >>not yet invented."

The above statement is not correct. Ad hoc queries have been around as long as
long as I remember. They are supported in every database system I have used.
Constrained ad hoc queries are even more trivial. My estimate is that an
experienced programmer could implement the constrained ad hoc query approach I
have advocated in about a week or two for the Registry.

I respectfully submit that this is not a convincing or viable alternative.


"Nieman, Scott" wrote:

> I am going to call a vote VIA THIS LIST.
> Very simple vote.
> My vote: NO.
> Explanation: NOT NOW. My opinion is simple.  While there are elements of
> this document that have some good thought into it, I think this counter
> proposal needs so much work that we will never get a product into QR. Move
> the existing RIM and RS to QR.
> I recommend a NO vote because:
> - Its not obvious to my how this proposal is better than the existing
> proposal (from a pros cons point of view).
> - the state of this document needs work
> - the estimated time to incorporate this document is great
> - the "dynamics" of this project team reminds me of a bunch of old mules
> that prevent us from agreeing on a quick path
> We'll have more time to talk later about this document, as I want more
> information such as the origin etc.   I do see some interesting use cases,
> but again, not enough time.
> Regarding the vote, I would also appreciate those who are participating in
> the POC for the registry to indicate in the body text, before your vote
> result, so I can categorize the results.
> Tally by the telecon, and if the vote is a tie, we discuss gory details on
> Monday.
> Scott
> -----Original Message-----
> From: David RR Webber
> To: ebxml repository
> Sent: 1/12/01 12:33 AM
> Subject: Counter Proposal Paper Draft 0.9
> Attached PDF,
> DW.
>  <<adhoc-query-api.PDF>>

org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
fn:Farrukh Najmi

[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