Implicit schema attributes for searchable reference types

[Gary P Cole <Gary.P.Cole@Sun.COM>]

I won't be on the conference call tomorrow--I have a prior 
commitment--but I wanted to share my thoughts on the issue we agreed to 
revisit: implicitly representing as attributes in the target schema 
reference types that the provider wishes to support as queryable via the 
standard 'search' operation.

I wasn't very happy about this at the time--it just seemed to be the 
lesser evil.   But after thinking about it some more, maybe it's not so bad.

First, recall that we had earlier decided that we must normatively 
specify the following:
     "The 'lookup' operation always returns references
      if the reference capability is supported (by the target)".
This is one example of a supported capability implying some undeclared 
behavior.

If we want to take a similar line with reference types, perhaps we could 
add an attribute called 'queryable' (or 'searchable' or 'canQuery' or 
'canSearch'...) to the ReferenceType declaration.  I don't have the 
syntax in front of me, but we were specifying things like fromType and 
toType and cardinality.  A flag that says whether references of that 
type are searchable (or an attribute that names an implicit schema 
attribute) doesn't seem too bad.

Another possibility is to allow the provider to "inject" the attribute 
corresponding to each searchable reference type into the target schema.  
Gerry Woods mentioned that it is sometimes undesirable to tamper with 
the well-known schema of a service or system, but I think we've often 
assumed that the provider could or would manipulate the native schema to 
produce the target schema.  If this is true, then perhaps it's not so 
big a sin to expect the provider to represent each queryable reference 
type in the target schema.

Of course, it is not strictly necessary for a provider to represent each 
searchable reference type in the target schema.  I believe it is highly 
desirable because it lets the provider declare (in a way any requestor 
should understand) which reference types are searchable and what 
attribute to use.

In the case where a reference type is complex, however, it may actually 
be necessary.  Because a complex reference has a structure, it seems 
natural to represent this in the schema.  Because a complex reference is 
likely to be bound (as a sub-object) beneath one of the connected 
objects, it seems even more natural to represent this in the schema.

Good luck tomorrow.

Gary