Re: Combining "Browse & Drilldown" and "Filter Query"

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Len,

Thanks for the examples of how filter queries could replace browse and drill down
queries. It was very helpful.

Could we extend string matching in filter query to support an 'LIKE' patterns as
in SQL Query. This would make the two consistent and it would also make filter
query more capable.

I am a little uneasy about having no focused query support but willing to explore
the idea further. My concern is that filter queries may be hard for clients to
use in an intuitive manner. The original rationale for focused queries was to
make the 80% queries be really obvious and let the other 20% query cases be
handled with filter and SQL queries.

Please see a few more comments inline below:


Len Gallagher wrote:

> Query folks,
>
> Given the affirmative responses from team members earlier today to the
> suggestion that we might be able to combine the following two section of ebRS
>
>   - Section 8.1 Browse and Drill Down Query Support
>
>   - Section 8.2 Filter Query Support
>
> into one section, I offer the following discussion. Since the Filter Query
> is intended to be broader in scope than Browse and Drilldown, I discuss how
> each Browse and Drilldown alternative could be represented as a FilterQuery
> and indicate where I think new FilterQuery alternatives need to be
> specified in order to capture all of the intended functionality.
>
> I'll depend upon the old DTD synatax from RS instead of the proposed new
> XML schema syntax, since I'm more familiar with the DTD's and assume that
> the XML schema is upward compatible with it.
>
> Section 8.1.1  Get Root Classification Nodes Request
>
>  From Appendix A the DTD syntax is:
>
> <!ELEMENT GetRootClassificationNodesRequest  EMPTY >
> <!ATTLIST GetRootClassificationNodesRequest
>      namePattern    CDATA    "*"  >
> <!ELEMENT GetRootClassificationNodesResponse ( ClassificationNode+ )>
>
> This syntax assumes that the "Root" node of every classification scheme is
> represented as an instance of ClassificationNode. Part of the new proposal
> to modify ebRIM would modify that assumption. If that proposal passes,
> ClassificationScheme will be a new subtype of RegistryEntry. Each root node
> instance in ClassificationNode would be replaced by a ClassificationScheme
> instance.
>
> Assuming that the RIM re-structure proposal passes, the requirements of
> GetRootClassificationNodesRequest could be met by a filter query on
> RegistryEntry (cf Section 8.2.2) as follows:
>
>   <RegistryEntryQuery>
>      <RegistryEntryFilter>
>         objectType EQUAL "ClassificationScheme"
>         AND
>         name CONTAINS "someString"
>      </RegistryEntryFilter>
>   </RegistryEntryQuery>
>
> In addition, all of the other flexibility of <RegistryEntryQuery> would be
> available to further restrict the ClassificationScheme ID's returned by
> this query. I believe that no additional specification is needed to handle
> all of the requirements of Section 8.1.1.
>
> Section 8.1.2  Get Classification Tree Request
>
>  From Appendix A the DTD syntax is:
>
> <!ELEMENT GetClassificationTreeRequest  EMPTY >
> <!ATTLIST GetClassificationTreeRequest
>      parent    CDATA    #REQUIRED
>      depth     CDATA    "1"  >
> <!ELEMENT GetClassificationTreeResponse ( ClassificationNode+ )>
>
> The parent node is supplied and the query is supposed to return all of the
> ClassificationNode instances below the parent node for "depth" levels. This
> query also assumes that the ClassificationScheme is identified by the root
> node. If the RIM re-structuring proposal passes, the ClassificationScheme
> will have to be identified in some other way since the root node will no
> longer exist as an instance of ClassificationNode.
>
> The requirements of Section 8.1.2 are only partially addressed by the
> filter query on ClassificationNode specified in Section 8.2.4. The parent
> would have to be identfied by a filter on ClassificationNode and then each
> depth would have to be specified separately. This is clumsy and some
> re-specification of ClassificationNodeQuery is likely required to meet
> these requirements. I volunteer to help work on this needed
> re-specification. We need some shortcut to express the depth requirements
> of Section 8.1.2.

Thanks. Let me know if I can be of any help on that.

>
>
> But assuming that the parent node is known and we want only the next level
> of nodes, the following ClassificationNodeQuery would suffice:
>
>   <ClassificationNodeQuery>
>      <HasParentNode>
>          <ClassificationNodeFilter>
>              id EQUAL "KnownParentID"
>          </ClassificationNodeFilter>
>      </HasParentNode>
>   </ClassificationNodeQuery>
>
> In our re-structuring of RIM, I hope we have a requirement that each
> ClassificationNode instance needs to know the ClassificationScheme instance
> it comes from. Then we could define a new filter query branch, i.e.

I am not comfortable with requiring each node to know its scheme. It violates
keeping such knowledge encasulated and also adds more weight to each node
which would now have two refs instead of one (parent and scheme). Is this
necessary?

>
> <FromScheme>, and the following query would get all nodes of a given
> classification scheme:
>
>   <ClassificationNodeQuery>
>      <FromScheme>
>          <ClassificationSchemeFilter>
>              id EQUAL "KnownSchemeID"
>          </ClassificationSchemeFilter>
>      </FromScheme>
>   </ClassificationNodeQuery>
>
> I think some modification of this last query would allow one to specify how
> many levels, and which levels, of the tree one wants to have returned - but
> I leave the details for later.
>
> Section 8.1.3  Get Classified Objects Request
>
>  From Appendix A the DTD syntax is:
>
> <!ELEMENT GetClassifiedObjectsRequest  ( ObjectRefList )>
> <!ELEMENT GetClassifiedObjectsResponse ( RegistryEntryList )>
>
> The assumption is that ObjectRefList is a list of classification node
> references. The requirement is to return a list of RegistryEntry instances
> that are classified by ALL of the classification nodes in the
> ObjectRefList. By convention, classification by a sub-node of a node
> implies classification by the node.
>
> The basic requirement is satisfied by the RegistryEntryQuery as specified
> in Section 8.2.2. However, the RegistryEntryQuery has no notion of
> classification by a sub-node implying classification by a super-node. To
> get the full benefit of the nested classification requirement, the
> HasClassificationBranch of the RegistryEntryQuery may need re-specification
> to allow a client to indicate when they want an exact match to a node and
> when they want a nested match to any sub-node. I think a simple attribute
> on the HasClassificationBranch element would be sufficient to satisfy all
> requirements derived from Section 8.1.3. I volunteer to work on that
> enhancement of HasClassificationBranch.

Excellent idea.

>
>
> Suppose the ObjectRefList above has 2 classification nodes identified, i.e.
> Node1ID and Node2ID. The GetClassifiedObjectsRequest would want to return
> all RegistryEntry instances that are classified by BOTH Node1 and Node2.
> The following RegistryEntryQuery would suffice:
>
>   <RegistryEntryQuery>
>      <HasClassificationBranch>
>          <ClassificationNodeFilter>
>              id EQUAL "Node1ID"
>          </ClassificationNodeFilter>
>      </HasClassificationBranch>
>      <HasClassificationBranch>
>          <ClassificationNodeFilter>
>              id EQUAL "Node2ID"
>          </ClassificationNodeFilter>
>      </HasClassificationBranch>
>   </RegistryEntryQuery>
>
> Thus some minor modification of HasClassificationBranch would allow filter
> queries to satisfy all requirements of Section 8.1.3. In addition, all of
> the other flexibility of RegistryEntryQuery would be available to further
> restrict results returned by this query.
>
> **************************************************************
> Len Gallagher                             LGallagher@nist.gov
> NIST                                      Work: 301-975-3251
> Bldg 820  Room 562                        Home: 301-424-1928
> Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
> **************************************************************
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard