Re: [regrep-query] Re: getPath proposal and Path Filter proposal

[Len Gallagher <LGallagher@nist.gov>]

Farrukh and Query Team,

This is in reply to the Oct 10, 2001 revision of the proposal to add a 
simplied version of XPath Expression to our Registry Services specification,
   cf   http://lists.oasis-open.org/archives/regrep-query/200110/pdf00007.pdf


I still have the same comments on Section 3.2, "Use of Path Filter 
Expressions in ClassificationNodeQuery".


> > Lines 64-75 - Major
> > This section is supposed to define the semantics of how a "pathFilter
> > expression" works when applied to a getPath() result. But it just says that
> > the Semantic Rules for ClassificationNodeFilter should be extended.  The
> > example uses EQUAL syntax as defined in the Clause element (cf ebRS v1.0,
> > section 8.2.10) but doesn't propose any changes to that section. The
> > example doesn't show any relationship to the XpathNodeExpression defined in
> > line 33. Shouldn't this section also point to the appropriate sections of
> > the XPath 2.0 specification for the specification of how two slashes (i.e.
> > "//") and the "*" wildcard are to be interpreted. Do we have any guarantee
> > that the intended uses of "slashes" and wildcard used here is identical to
> > that defined by XPath?


What's really needed in Section 3.2 are some formal definitions that can 
leverage the XPath 1.0 specification. What we have now in this proposal is 
some syntax defined in Section 3.1 and no semantics at all. We can't rely 
on the informative examples of this proposal as a substitute for a testable 
specification.

I'd like to see the following Requirements in any proposal that we accept 
for inclusion in ebRIM and ebRS.

1) An XML definition of a document type that will be the contextual 
document of an XPath expression. Recall that XPath only makes sense with 
respect to a well-formed XML document!

2) A definition of the getPath() method in ebRIM that will allow the result 
of that method to be interpreted as a well-formed XML document.

3) A specification of #PCDATA for an XpathNodeExpression that can be 
interpreted as a restricted subset of XPath 1.0 syntax.

4) Rules for how to apply the simplified XPath node expression to the 
result of the getPath() method so that one is able to determine if the node 
satisfies the Xpath expression. Then decide if this should be embedded into 
our Clause syntax for string comparison, i.e. using EQUAL.


Requirement 1

Suppose we define the following XML elements:

<!ELEMENT NodeRepresentation ( ClassificationScheme?, ClassificationNodePath )>

<!ELEMENT ClassificationNodePath ( ClassificationNode, 
ClassificationNodePath? )>

Since ClassificationScheme (as a subtype of RegistryEntry) and 
ClassificationNode are already defined as XML elements in Appendix A, we 
can treat NodeRepresentation as an XML DTD.


Requirement 2

Suppose we define the result of the getPath() method to be a string that 
can be interpreted as a virtual XML document that validates to the 
NodeRepresentation DTD. In addition, we require the following mapping from 
our Registry UML model in ebRIM to a NodeRepresentation.

For each application of the getPath() method to a given ClassificationNode 
instance:

a) The ClassificationScheme instance in the getPath() result shall be the 
ClassificationScheme instance resulting from the getClassificationScheme() 
method applied to the given instance.

b) The last ClassificationNode instance in the NodeRepresentation shall be 
the given instance.

c) The parent attribute of each ClassificationNode element in the 
NodeRepresentation shall point to the ClassificationNode element in the 
containing ClassificationNodePath.

With these assumptions, the getPath() result can be treated as a 
well-formed XML document that is the contextual document of an XPath 
expression.


Requirement 3

We can treat the #PCDATA of the XpathNodeExpression in a query to be the 
"pathFilter" defined in section 3.1 of the proposal. As such it could be 
interpreted as a representation of an XPath expression on any document that 
validates to the NodeRepresentation DTD. We could do this by treating the 
"pathFilter" syntax defined in Section 3.1 of the proposal as follows:

  pathFilter is preceded by the text:  document("NodeRepresentation")

  schemeId is shorthand for the text:  ClassificationScheme[id="schemeId"]

  nodeCode is shorthand for the text:  ClassificationNode[code="nodeCode"]

I think this is sufficient in order to interpret every "pathFilter" as an 
XPath expression applied to the NodeRepresentation returned by a getPath() 
method.

We still have to resolve problems with how to treat the XPath special 
symbols (e.g. /, @, ", ::, ==>, *, ., .., [, ], etc.) if they appear as 
characters in the code attribute of ClassificationNode.


Requirement 4

Left as an exercise for the reader. Does it make sense to treat the result 
of getPath() and the #PCDATA in XpathNodeExpression as a true or false 
result of the following string comparison?

    getPath() EQUAL "pathFilter"


CONCLUSION

I must admit that I'm still dubious about the wisdom of proceeding in this 
direction! With the getPathElements() method defined for 
ClassificationNode, and with PathElementFilter defined as proposed for 
FilterQuery, I think we get equivalent functionality with less hassle.

-- Len