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



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