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

[Waqar Sadiq <wsadiq@vitria.com>]

I am not yet clear how an API based approach to providing queries can allow
queries over the content - which is known ahead of time.  The aspect of
Farrukh's proposal that I liked most was the fact that I could index the
content and then arbitrarily query the content.  This open the door to some
additional uses of the registry that might not be otherwise be possible.
For example, schema for shipping/logistic service may choose to index their
content so that an automated order fulfillment system, looking for the best
shipper for their product, might query the service providers and look for
the cheapest shipper that will get the package to a certain destination in
the specified time.  This example might not be accurate but hopefully you
get the point.

My point is, that to date, we have looked at registry services as providers
of information, most likely to be consumed by humans ( and hence the browse
and drill down patterns of UDDI).  While this is certainly the most likely
usage in the near term, long term one can see automated exchanges that
enable consumer systems to search the content of the supplier systems in
order to make automated decisions.  To me it seems like that the ad hoc
capability as described in Farrukh's proposal is necessary for this kind of
search.

My $.02 cents worth. 

Waqar Sadiq
Vitria Technologies

-----Original Message-----
From: David RR Webber [mailto:Gnosis_@compuserve.com]
Sent: Friday, January 12, 2001 9:16 AM
To: Farrukh Najmi
Cc: 'ebxml repository '
Subject: Re: vOTE CALL: RE: Counter Proposal Paper Draft 0.9


Message text written by Farrukh Najmi
>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.<

>>>>>>>>>>>>>>>>>>>>

And the reason is because the details in msg00098.html are also EXTREMELY
vague and unimplementable - and the SQL examples offered up are flawed.

In working this last night I found that each RIM access method will need to
be
fleshed out in clear detail and the access metrics specified in plain
english text.
This is not ciurrently available.

Now - I would say that we do not have to have ALL of these done, just three
or
four good ones that clearly state the needed functionality.

Whereas you deride UDDI - they in fact have done this clearly and
succinctly.
And they have also realized - and you seem to have COMPLETELY IGNORED
this point that your beloved ad hoc query level of functionality is way
overkill,
very prone to vendor interpretation, and unnecessary.

Therefore I would state you are arbitarily and unnecessarily raising the
bar
10 feet of fhe ground here - when it only needs to be six inches.

Furthermore - the whole POINT of the method based approach is that it
does NOT provide chapter and verse code level detail - since that
will be highly vendor implementation specific.

Yes - it is a more flexible and extensible variant of the focus method 
approach - providing ad hoc ability to extend the access API services..

Therefore as I see it - we have a NO and a NO.  Two NO's make a no-go here.

DW.