OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


Title: Message
If so, how does this simplify/generalize the use of general_keywords?
 
Claus
 
-----Original Message-----
From: Daniel Feygin [mailto:feygin@unitspace.com]
Sent: Tuesday, June 29, 2004 5:13 PM
To: Von Riegen, Claus; 'Luc Clement'; 'uddi-spec'
Subject: RE: [uddi-spec] Removal of Section 2.3 keyName Changes - adding the capability of making keyName significant

Unless keyNameSignificant is specified, all aspects of V3 behavior apply, including special treatment for general_keywords.
 
Daniel


From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
Sent: Tuesday, June 29, 2004 4:53 PM
To: Luc Clement; 'uddi-spec'
Subject: RE: [uddi-spec] Removal of Section 2.3 keyName Changes - adding the capability of making keyName significant

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
 
-----Original Message-----
From: Luc Clement [mailto:luc.clement@systinet.com]
Sent: Tuesday, June 29, 2004 3:10 PM
To: 'uddi-spec'
Subject: RE: [uddi-spec] Removal of Section 2.3 keyName Changes - adding the capability of making keyName significant

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


From: Luc Clement [mailto:luc.clement@systinet.com]
Sent: Tuesday, June 29, 2004 14:42
To: 'uddi-spec'
Subject: [uddi-spec] Removal of Section 2.3 keyName Changes - adding the capability of making keyName significant

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]