[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: getPath proposal and Path Filter proposal
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 **************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC