[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Implicit schema attributes for searchable reference types
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]