[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: telecon
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. -- 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 **************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC