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

Tryign to further understand your proposal, can you clarify how would I
query the meta data of RIM where the query needs to be predicated over
multiple attributes?  So for example, how would I need to  retrieve a
specific version of a managed object whose name has some text in it.

The problem is that soon as you recognize the need to query multiple
attributes, you have a combinatorial explosion which would be difficult to
handle with a API based approach.  At the same time, I sympathize with your
concern about execution of poorly formulated queries becoming an unneccasry
burden on registry implementations.  That is why, personally I am in favor
of supporting SQL syntax with constraints on the SQL so that features of SQL
which are not necassary will not be supported.  Just, and strictly, as an
example, the specification may say that joins will not be allowed or the
keyword DISTINCT will not be supported e.t.c.


Waqar Sadiq
Vitria Technologies

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

Well Waqar,

I like your business points because these were the 
points I was making too. Machine-machine.  

Notice that the 'specific' style ad hoc API 
will  allow you to develop what is essentially a custom query
method to do the business functionality detailed below - and 
then expose that so people can come in discover it - find out 
what parameters it needs - and then invoke it.  you'd have to 
set this all up for them - which is the WHOLE point - they are 
unlikely to know enough about your industry, information mapping
and internals to be able to discern this easily themselves externally.

Now - on to the other point - exposing an interface that allows 
anyone to write any SQL against your backend is not what your
DBA would counteneance - just go and ask them right now and
see what you get as an answer!

Message text written by Waqar Sadiq
>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

[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