[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Combining "Browse & Drilldown" and "Filter Query"
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. 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. <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. 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 **************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC