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                             
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************