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: Re: telecon


Please see equivalent XPATH syntax below since Len indicated he was not sure of
the syntax.

Please note that I see any use case that justifies the need for levels. Can any
one in the team indentify a use case that justifies the need for levels? This
is not a rhetorical question. I genuinely want to know.

Len Gallagher wrote:

> Dan and Query team,
>
> This is a response to a question from Dan identifed below.
>
> I agree that the PathElementFilter presented as one of three options for
> the XML HasPathBranch element in the FilterQuery proposal is NOT completely
> specified in the proposal.  See my discussion of the alternatives in a
> previous email to this list:
>
>    http://lists.oasis-open.org/archives/regrep-query/200109/msg00079.html
>
> I may be the only person who has a soft spot in favor of the
> PathElementFilter alternative, but my intention is to make it a complete
> alternative by proposing a new getPathElements() method on the
> ClassificationNode class in ebRIM. Then people can decide to accept or
> reject it on its merits, rather than on whether or not its specification is
> complete.
>
> The getPathElements() method would act on a ClassificationNode instance to
> return a set of level/value pairs to identify the path leading to that
> node. For example, in the UNSPSC classification scheme, the
> getPathElements() method applied to the node for "Integrated circuit
> components" (UNSPSC code="321118") would return the following set of
> (level,value) pairs:
>
>     { (level="1",value="32"), (level="2",value="3211"),
> (level="3",value="321118") }
>
> Then a client constructing a query could use one or more PathElementFilter
> elements in the query  to achieve the same capabilities as the XPATH
> alternative would give on that node. For example, a PathElementFilter with
> value="32" would return all nodes (or classifications) with "32" as its
> "code" at any level of the path. In particular, when used in a
> HasClassificationBranch it would return all items classified as "32" or any
> subnode of "32". I'm not an XPATH expert, but I think the equivalent XPATH
> expression would be path="//32//"

The correct syntax would be path="//32"
'//' means any descendent of the path element preding the '//'

>
>
> Similarly, in the Geography classification scheme used in some of our
> examples, the Asia/Turkey node under Geography could be identified with two
> separate PathFilterElement's where the first specifies level="1" AND
> value="Asia" and the second specifies level="2" AND value="Turkey". The
> equivalent XPATH expression would be path="//Asia/Turkey".  NOTE: we need
> both levels because "Turkey" might also be a node under "Europe". If in a

XPATH allows the following:

//Turkey which will match all nodes with value Turkey (both under Asia and
Europe)

>
> later version of our spec we allow named levels, as has been proposed, then
> the PathFilterElement's might evolve to a more meaningful level="Continent"
> AND value="Asia" and level="Country" AND value="Turkey". I'm not sure what
> the equivalent XPATH expression would look like.

The equivalent XPATH expression would be:

/Continent/Asia/Turky

Alternatively to match both instances of Turkey (under Europe and Asia) you
would say:

/Contonent//Turkey

>
>
> NOTE: I'll make the complete proposal for a getPathElements() method on the
> ClassificationNode class later today so we'll have it.
>
> -- Len
>
> At 07:05 PM 10/5/01, Dan Chang wrote:
> ... deleted some stuff
>
> >Len,
> >
> >I forgot to bring this up. Please let the team know how you would like to
> >get issues related to PathElementFilter resolved so that we can make a
> >decision one way or another.
> >
> >Regards,  Dan
> >
> >Metadata Management Technology and Standard
> >IBM DBTI for e-Business
> >Notes:     Dan Chang/Santa Teresa/IBM@IBMUS
> >Internet:  dtchang@us.ibm.com
> >VM:          IBMUSM50(DTCHANG)
> >Phone:    (408)-463-2319
>
> .. deletd some more stuff
>
> **************************************************************
> 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

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