uddi-spec message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [uddi-spec] Removal of Section 2.3 keyName Changes - adding the capability of making keyName significant
- From: "Von Riegen, Claus" <claus.von.riegen@sap.com>
- To: Daniel Feygin <feygin@unitspace.com>, "'Luc Clement'" <luc.clement@systinet.com>, "'uddi-spec'" <uddi-spec@lists.oasis-open.org>
- Date: Wed, 30 Jun 2004 06:59:59 +0200
Title: Message
If so,
how does this simplify/generalize the use of
general_keywords?
Claus
Unless keyNameSignificant is specified,
all aspects of V3 behavior apply, including special treatment for
general_keywords.
Daniel
Although the simplification of the matching behavior with regard to
general_keywords is a kind of weak requirement IMO, I am still trying
to understand on how general_keyword would work if the proposal below would be
adopted.
Would
the missing keyNameSignificant find qualifier applied
to a keyedReference to the general_keywords tModel without a keyName
be allowed then? If so, how would it be different from a specified
keyNameSignificant findQualifier in combination with the approximateMatch
find qualifier? One would find all general_keywords categorizations with a
certain keyValue, regardless of the keyName, in both cases. I don't
see how this would simplify the application of general_keywords as long as
keyNameSignificant would not be implicitly applied for general_keywords, which
is an exception from the general matching rule as it is specified
now.
Claus
Daniel suggested the following restatement of the
proposal:
It is proposed
that a new find qualifier keyNameSignificant be added to control the
significance of keyName in queries. In keyNameSignificant mode all
keyName attributes specified in keyedReference elements of a query would be
treated as significant for the purpose of
matching.
V3 ignores keyName in searches for all practical
purposes, except when the corresponding keyedReference's tModelKey refers to
general_keywords category system, in which case keyName is required and is
significant in all contexts.
keyNameSignificant is not active by default, consistent
with V3 behavior.
We still need to justify
this proposal through use cases else no work is planned to take this forward. We
would like to get your input on this.
Luc
Prior to today,
Reqt/Prop 20 was suggesting that we allow keyName to be a significant query
parameter. During the FTF, we could not find compelling use cases justifying
adding this capability.
We would like to
get your input on this. Section 2.3 was:
2.3 keyName
Changes
Further, it is proposed that keyName become a significant query
parameter. V3 ignores keyName in
searches for all practical purposes, except when the corresponding
keyedReference's tModelKey refers to general_keywords category system, in
which case keyName is required and is significant in all contexts. Making keyName significant in all
searches in which it is specified would make keyName matching behavior
consistent across the general case and the general_keywords case, taking away
the ("magical") special treatment of general_keywords.
Could the TC provide
supporting arguments in favour or not of this requirement. As it stands, it's
been removed from Prop 20 [1].
Luc
Luc
Clément
Secretary, OASIS UDDI
Spec TC
Systinet Corporation
Tel:
+1.617.395.6798
[1] http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/7516/uddi-spec-tc-prop020-ExtendedFindQualifiersForBags-20040629.doc
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]