Explaining the 3 alternatives for HasPathBranch

[Len Gallagher <LGallagher@nist.gov>]

Query team,

Yesterday I distributed a revised proposal for FilterQuery to this list. 
The proposed XML syntax has an element defined as follows:

   <!ELEMENT HasPathBranch
     ( PathFilter  |  XpathNodeExpression  | PathElementFilter+ )>

The intent is that one of these alternatives would be used when trying to 
query the results of the getPath() method described (but not yet defined!) 
in Section 10.2.4 of ebRIM v1.1.

The first two alternatives assume that getPath() returns a character 
string. The first alternative would treat that string as a primitive string 
data type that could be queried by the StringClause syntax defined in 
Section 8.2.10 ebRS v1.1. The second assumes that the string could be 
queried by a subset of XPATH syntax (see Farrukh's email from earlier today).

The third alternative assumes that getPath(), or a new ebRIM method, 
returns a collection of ordered pairs, i.e. { (level, value) }, where level 
identifies the "level" of each node in the hierarchical path of its parent 
classification scheme, and where value is the value of the attribute 
ClassificationNode.code (cf Section 10.2.1 of ebRIM). This alternative 
assumes that the path leading up to the identified node could be queried by 
separate Clause predicates on each of its levels. A path would "satisfy" 
the HasPathBranch element if each of the PathElementFilter's was satisfied.

ADVANTAGES and DISADVANTAGES

PathFilter
  Advantages: Already completely defined, uses existing ebRIM defns
              and existing ebRS Clause syntax.
  Disadvantages: Not very robust. Could benefit from additional
                 methods defined in ebRIM, e.g. getPathDepth() to return
                 an integer that could be queried by the existing predicates
                 for IntClause already defined in ebRS Section 8.2.10.

XpathNodeExpression
  Advantages: Leverages the popular, powerful, and convenient XPATH syntax.
  Disadvantages: Not yet defined in ebRS.

PathElementFilter
  Advantages: Does not require extensions to existing ebRS Clause syntax.
              Allows powerful queries on a par with Xpath.
  Disadvantages: Quite clumsy to express useful query requests!
                 Depends on a method, i.e. getPathElements(), not yet
                 defined in ebRIM.

DISCUSSION

It's possible that these three alternatives might be combined in some 
fruitful way, but for now they are treated as three separate alternatives. 
For example, XPATH syntax might be incorporated at the StringClause level 
of the existing ebRS Clause (cf Section 8.2.10 of ebRS). If that happened, 
then the XpathNodeExpression could be deleted in favor of the PathFilter 
alternative.

Regards,
Len


**************************************************************
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
**************************************************************