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



Farrukh,

Force fitting URN into name or id is not proper:
(1) The name attribute has a data type of LongName (128 chars). The id
attribute has a data type of UUID (64 chars). URN should have a data type
of URI (256 chars).
(2) It prevents people from using name or id as what it is intended for.
(3) It causes confusion even when name or id is not needed.

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


                                                                                                       
                    Farrukh Najmi                                                                      
                    <Farrukh.Najmi       To:     Nikola Stojanovic                                     
                    @Sun.COM>             <nikola.stojanovic@encodasystems.com>                        
                                         cc:     regrep-query@lists.oasis-open.org                     
                    09/28/01 06:49       Subject:     Re: Canonical Path and Path Filter proposed      
                    AM                    specificatrion                                               
                                                                                                       
                                                                                                       
                                                                                                       





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




#### najmi.vcf has been removed from this note on September 28 2001 by Dan
Chang





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


Powered by eList eXpress LLC