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


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [provision] Search on references

My basic idea for searching on references (and any other capability data
that may be provided in the future) is to add "and", "or", and "not"
expressions in the search capability. These elements would be able to
express the joining of profile specific query expressions (such as DSML v2
search filters) and capability specific query expressions (such as "has
reference" from the reference capability). For instance if the service uses
the DSML v2 profile, a search query could be defined as all PSOs satisfying
a specific DSML v2 search filter and being a member of a certain group:
This feature would require defining the following elements:
A couple of points here:
1) The use of XPath as a query expression is only one of many possible
mechanisms. For instance the DSML v2 Profile does not use XPath but rather
uses the DSML v2 search filter as a query expression. the XSD Profile uses
XPath by definition, but other potential bindings such as an HR-XML or a
Liberty Profile may not.
2) Obviously search performance is a critical issue. For the DSML v2 Profile
this is not a problem because any two DSML v2 search filters can be or'd or
and'd together to create a new filter with no loss of performance. I'm not
enough of an XPath expert to comment of how it would apply in the profile.
Perhaps an XPath guru to chime in on how to join multiple XPath expression
with an "and", "or", or "not".
Jeff Bohren

-----Original Message----- 
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Mon 4/4/2005 1:50 PM 
Subject: [provision] Search on references


Thank you for offering to explore the possibility that we can support a 
requestor searching based on references.  I don't know whether this will 
help, but I remember some of the issues that surrounded 
search-based-on-references when we discussed this at the Houston BMC 

One issue was the inelegance of expressing a search condition on 
something that was outside the schema, when elsewhere we used XPath to 
refer to schema-defined elements or attributes. 

Another issue was that it might be difficult (or performance-intensive) 
for a provider to combine reference conditions with 
schema-defined-element-or-attribute conditions.  Reference data might be 
managed by the provider separately and stored separately from 
schema-defined data managed by the system or application underlying a 
target.  Combining both types of conditions might require two-stage 
filtering (which might mean that the provider selects a lot of data from 
the target only to discard most of it during second-stage filtering). 

In the spec, my approach was to say that 
- a requestor may search only based on schema-defined elements or 
attributes, and that 
- a provider who wants to support search based on references may expose 
those references as elements or attributes in the target schema. 

The advantages of this approach are 1) that the same search mechanism 
works for both reference and schema-defined data and 2) that the 
provider controls the set of references on which a requestor may search. 

One disadvantage is that this approach defeats one purpose of separating 
references from schema-defined data.  If the provider models a reference 
type in the schema, then a requestor can no longer suppress that 
(reference) data simply by ignoring capability data. Another drawback is 
that the provider might have to "monkey with" a well-known schema in 
order to inject reference elements or attributes. 

What are your thoughts on supporting search based on references? 


To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  You may a link to this group and all your TCs in OASIS


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]