Re: getPath proposal and Path Filter proposal

[Len Gallagher <LGallagher@nist.gov>]

Query Team,

Attached are some comments on the proposed XPATH Subset Syntax definition 
distributed to this Query team last Friday.

   http://lists.oasis-open.org/archives/regrep-query/200110/pdf00002.pdf

Many of these comments are identical to those I made just a few minutes ago 
on the getPath proposal, which was also part of last Friday's distribution.

   http://lists.oasis-open.org/archives/regrep-query/200110/msg00023.html

so I'll concentrate on new comments:

Line 36 - minor
Shouldn't "path filter expression" be "pathFilter expression" since that is 
the definition in Line 46?

Line 36 - Major
Not clear what "include" means.  Can I have a whole bunch of text with a 
"pathFilter" expression somewhere in the middle of it, or must the content 
of the #PCDATA be like demonstrated in the example on Line 68?

Lines 46 and 57 - Major
Same comment re: "schemeId" as discussed for the getPath() method proposal.

Lines 54-56 - Major
Same comment re: "ID" limitations as discussed for the getPath() method 
proposal.

Lines 59-71 - 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 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?

Lines 76-83 - minor
Shouldn't the RHS of all of the "parent" attribute references end in "-id"?

Line 84 - minor
In the first row of the table, it's not clear to me if the intended 
semantics of the PATH Expression is to return ONLY first level nodes, or 
all nodes with "NorthAmerica" as the code value of the first level element. 
It will help if you add a second example with pathFilter as 
"/Geography-id/NorthAmerica/*" if the "*" at the end is supposed to mean 
"Find all nodes whose first level path element has code "NorthAmerica". 
It's not clear that this use of the "*" wildcard means any number of 
following elements because the definition in line 42 says it matches only a 
single path element. Will it find all nodes whose getPath() results have 4 
path elements instead of just 3?

Lines 109-113 - minor
The example appears that it would return ALL nodes in the identified 
ClassificationScheme, not just those nodes beneath a given 
ClassificationNode instance. This should be an easy correction!

I hope these issues can be resolved before we have to vote on this proposal.

-- Len




At 10:16 PM 10/5/01, Farrukh Najmi wrote:
>Team,
>
>In todays con call I was asked to re-submit my original proposal for the
>syntax of ClassificationNode getPath method and Path expression for
>filter queries as two separate proposals. The original proposal may be
>found at:
>
>  http://lists.oasis-open.org/archives/regrep-query/200109/msg00075.html
>
>A related comparison of path filters and other approached is at:
>
>http://lists.oasis-open.org/archives/regrep-query/200109/msg00047.html
>
>Attached are both proposal for your consideration.
>
>--
>Regards,
>Farrukh
>
>
>

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