OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-query message

[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