RE: [uddi-spec] Do ranges require more FindQualifiers?

["Daniel Feygin" <feygin@unitspace.com>]

Title: Message

I think the general case of intersect will suffice for most purposes, with post-processing performed by the client as necessary.  Server-side support may be provided in the form of three mutually exclusive find qualifiers, performing the function of a three-way switch.  I did not include that in my proposal, because I thought it would not be very useful since such find qualifiers would apply indiscriminately to all ranges specified in the query.  That may lead to unexpected consequences if some part of the query came from a component that was unaware of the search modifiers.  Limiting range matching behavior to a single consistent pattern would eliminate this possibility, although at a cost of potential additional client-side filtering.  I do not have a strong opinion on this.

 

I do not like the idea of qualifying the intersection with a minimum overlap parameter, because I cannot see how that can be supported within the current inquiry paradigm.

 

Daniel

---

From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
Sent: Wednesday, March 24, 2004 9:30 AM
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] Do ranges require more FindQualifiers?

It just struck me that if we will be storing ranges in the registry, and allowing them in queries, we'll need more FindQualifiers to deal with the possible range v range requests:

1. subset = the range in the find request is a subset of the range stored
   I need this resource between 9 and 10, it is available between 8 and 12 - match
2. superset = the range in the find request includes all of the range stored
   I need the resource range to fall between 10 and 100, it is 30 to 40 - match
3. intersect = the range in the find request overlaps with the range stored (perhaps by a minimum amount)
   I need at least one hour of this resource between 9 and 12, it is available 8 to 10 - match

Those are the obvious ones, and the last one requires an additional parameter (I wonder where we can put that extra parameter?).

 

What do you think?

 

Tony Rogers

Computer Associates

Senior Architect

tel +61 3 9727 8916

fax +61 3 9727 3491

tony.rogers@ca.com