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: Canonical Path and Path Filter proposed specificatrion


That does avoid teh problem but then requires the user to specifify that using
more verbose XML constructs.

Another possibility is that we say the first part of the path is not the well
known URN but it is whatever the id attribute
(guarenteed unique) for the ClassificationScheme. This too avoids the URN issue
entirely.

Len Gallagher wrote:

> Query team,
>
> One way to avoid the "SchemeURN" issue is to NOT require that the
> classification scheme be identified as the first element returned in the
> getPath() method.  Instead, we could rely on the separate, already
> existing, getClassificationScheme() method to get an identifier for the
> parent classification scheme. That would leave us free to specify that the
> getPath() method returns just the delimited occurrences of "codes" from the
> first to last nodes in the path.
>
> Example: Assuming the NIACS Classification Scheme with the node having
> code="441221" and name="Motorcycle Dealers" we should decide if getPath()
> returns:
>
>   Choice 1)   "/44/441/4412/44122/441221"
> or
>   Choice 2)   "urn:www.census.gov:naics:naicscod.txt/44/441/4412/44122/441221"
>
> I realize that this is a personal preference decision and that either style
> will work, but in view of the already existing method to get the
> classification scheme, I see no compelling reason to repeat that
> information in the getPath() method.
>
> -- Len
>
> At 11:33 AM 9/28/01, Nikola Stojanovic wrote:
> ><Farrukh>
> >Per action item from previous team meeting I have attached an initial
> >proposal for your consideration and discussion in tomorrows meeting.
> ></Farrukh>
> >
> >I'd like to emphasize that the current proposal has an open issue of
> >handling a "SchemeURN" (line 91). I see a need for further discussions on
> >requirements for and semantics of "SchemeURN".
> >
> >Regards,
> >
> >Nikola Stojanovic
> >Lead Technologist, Research and Development
> >Encoda Systems Inc.
> >101 Pineview Terrace
> >Ithaca, NY 14850 USA
> >nikola.stojanovic@encodasystems.com
> >Tel: 607-273-2224
> >
> >
> >
> >
> >
> >----------------------------------------------------------------
> >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
> **************************************************************
>
> ----------------------------------------------------------------
> 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