Re: Canonical Path and Path Filter proposed specificatrion

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

I want to second that thought. I did not get a chance to discuss this issue
with Nikola. However, I feel that if we understood the needs better we would
likely have a better solution.

Some options to consider before the meeting are listed below:

Embed URN In Use id Attribute
----------------------------------
The RS says that the attribute is a URN (which may be urn:uuid or
urn:somethingelse). We could define a urn namespace for ebxmlrr (e.g.
urn:oasis:names:tc:ebxml-regrep:<registry-id>: ) where we put the scheme URN
as a suffic. For NAICS that would be something like:

urn:oasis:names:tc:ebxml-regrep:registry:<registry-id>ntis-gov:naics:1997

We could use above style URN as teh value of the id attribute of
ClassificationScheme. The resulting Id would be unique and would have the
well known URN for the scheme oin the Id. This is the better long term
solution.

However, this gets into space of Inter Registry Cooperation and requires more
deep thought.

Use URN In name attribute
-----------------------------
This means that the name attribute of ClassificationScheme may be the well
known URN for that scheme an it must be unique among all other scheme names
in the registry.

Thus in the NAICS example the name attribute for the NAICS
ClassificationScheme would be ntis-gov:naics:1997. The decsription attribute
could say any other human friendly description such as spelling out NAICS
acronym etc.

This is also the approach UDDI has taken.

Final Reccomendation
-----------------------
My final reccomendation for the proposal is to use the second option (Use URN
In name attribute) as it addresses the use case and does not require any more
specification.

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>

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