[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. Thanks, 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! DW. =================================================================== 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 search. <
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC