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: getPathElements() method on ClassificationNode



Query team,

Earlier today I sent an email to this list offering to complete the 
PathElementsFilter option for the HasPathBranch element in a FilterQuery. 
The text of that email, with examples, follows below.

Attached is a 2-page Proposal (PDF file) that would add the necessary 
getPathElements() method to the ClassificationNode class of ebRIM. This 
proposal has the advantage that it provides a PathElementsFilter with all 
of the functionality of an XPATH expression on the "path" of a node, with 
no requirement to define XPATH-like syntax and no requirement to extend our 
existing Clause syntax. The drawback of using PathElementFilter's instead 
of XPATH is that the syntax doesn't look as pretty.

-- Len


At 09:34 AM 10/9/01, 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//"
>
>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 
>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.
>
>NOTE: I'll make the complete proposal for a getPathElements() method on 
>the ClassificationNode class later today so we'll have it.


OK -- keep going down -- it's attached to this email!


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

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

getPathElements.pdf



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC