[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [regrep-query] Re: getPath proposal and Path Filter proposal
Len, Thnaks for your excellent feedback. Len Gallagher wrote: > 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? Done > > > 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? Agreed. I have added a schema fragment that defines the exact content of XpathNodeExpression. > > > Lines 46 and 57 - Major > Same comment re: "schemeId" as discussed for the getPath() method proposal. As stated in proposal "1. Issues dealing with multiple co-operating registries are not considered. These issues are deferred to the Inter Registry Cooperation (IRC) team.". I believe the proposal should not change in this area. > > > Lines 54-56 - Major > Same comment re: "ID" limitations as discussed for the getPath() method > proposal. This is a very valid comment. Note that I have made the nodeCode be any valid string as defined by XML Schema spec. > > > 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"? > Agreed. Fixed typo. > > 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". That is correct interpretation of the example you give. I will add it as second example as suggested. > > 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? Reworded to make clear. > > > 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! Thanks. This is fixed now. > > > I hope these issues can be resolved before we have to vote on this proposal. Let me know if you have any other suggestions. > > -- 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 > ************************************************************** > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> -- Regards, Farrukh
pathExpressionForRS-Oct10-2001.pdf
begin:vcard n:Najmi;Farrukh tel;work:781-442-0703 x-mozilla-html:FALSE url:www.sun.com org:Sun Microsystems;Java Software adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA version:2.1 email;internet:najmi@east.sun.com fn:Farrukh Najmi end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC