|
My e-mail got distorted (there were supposed to be 3 items, with an example
for each) - I should know better than that :-)
I do believe that at the very least we need to be able to specify the
behaviours I've labelled as subset and superset - whether the range on the query
must be completely contained in the range on the object, or vice versa, for a
match. These two would seem to be the bare minimum. (I'm less convinced about
the intersection) I would definitely not categorise either of these as an
approximate match - that concept just doesn't "fit".
I suppose exact match is reasonable, but it seems less useful with ranges
than with individual values. BTW: I would assume that the exactness extends to
the inclusivity of the bounds (lower bound of 10 inclusive does not exactly
match lower bound of 10 exclusive).
-----Original Message-----
From: Tom Bellwood
[mailto:bellwood@us.ibm.com]
Sent: Thu 25-Mar-04 8:13
To: Rogers, Tony
Cc: uddi-spec@lists.oasis-open.org
Subject: Find qualifiers in search ranges + related updates for Req
23
I'm not convinced we need the all of these, but I agree some control here
is requiredl. IMO we should try to keep the behavior here consistent with
default behaviors expressed elsewhere. "exactMatch" is the default matching
behavior and it already covers keyName and keyValue data in keyedReferences.
It should be enhanced to apply to the various members of the
keyedReferenceRange structure, including lowerValue, upperValue,
lowerInclusive, upperInclusive and inverted. Better yet, we should also
consider defining keyedReferenceRange to contain a keyedReference plus these
other new elements/attributes we added. This would simplify the spec and the
changes we have to make to take this related structure into
account.
While we're at it, all of the other FQ's which reference bag
elements need to be updated to take keyedReferenceRange into accoung (for
example, caseSensitiveMatch and caseInsensitiveMatch need to now also include
lowerValue and upperValue, and so on).
As for the qualifiers you've
identified, should we look at trying to extend the approximateMatch notation
and rules to achieve most of what's desired and add any new FQ's needed after
that?
Thanks,
Tom Bellwood Phone: (512) 838-9957 (external); TL:
678/9957 (internal)
Co-Chair, OASIS UDDI Specification TC
STSM -
Emerging Technologies
IBM Corporation
To: <uddi-spec@lists.oasis-open.org>
cc:
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:
- 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
- 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
- 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
|