RE: [uddi-spec] Removal of Section 2.3 keyName Changes - adding the capability of making keyName significant

Title: Message

The intent of general_keywords, if I understand it 
correctly, was to simplify the application of keywords to UDDI 
entities.  Indeed, general_keywords is a fairly simple concept.  
keyName changes we are considering are not designed to simplify 
the 
use of general_keywords.

Generalizing significance of keyName beyond 
general_keywords taxonomy is possible if keyNameSignificant find qualifier is 
removed or replaced with something like keyNameInsignificant, which would have 
the effect of keyName significant mode being applied by default.  That has 
the drawback of slightly complicating the porting to v.Next of existing queries 
that (for unbeknown reasons) include values for keyName 
attribute.

 

Daniel

 

From: Von Riegen, Claus 
[mailto:] 
Sent: Tuesday, June 29, 2004 10:00 
PM
To: Daniel Feygin; 'Luc Clement'; 'uddi-spec'
Subject: 
RE: [uddi-spec] Removal of Section 2.3 keyName Changes - adding the capability 
of making keyName significant

If so, 
how does this simplify/generalize the use of 
general_keywords?

 

Claus

 

-----Original Message-----
From: Daniel Feygin 
[mailto:] 
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:] 
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:] 
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:] 
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幦ent                        

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