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

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

My Vote: NO

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

http://lists.ebxml.org/archives/ebxml-regrep/200101/msg00098.html

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

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.

--
Regards,
Farrukh


"Nieman, Scott" wrote:

> I am going to call a vote VIA THIS LIST.
>
> Very simple vote.
>
> SHOULD WE CONSIDER THIS DOCUMENT AT THIS TIME?  (YES/NO with explanation)
>
> 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>>



begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard