OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

chairs message

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


Subject: RE: [chairs] What can Standards Development / TC Administration doto help?


People still use urn based ns?

-----Original Message-----
From: Robin Cover [mailto:robin@oasis-open.org] 
Sent: Thursday, April 22, 2010 9:45 AM
To: Marc Goodner
Cc: Patil, Sanjay; Bob Freund; Martin Chapman; Mary McRae; chairs@lists.oasis-open.org
Subject: RE: [chairs] What can Standards Development / TC Administration do to help?

> put guids in namespaces assigned for TCs[' specifications] :-)

That would be a good test of the assertion that TCs don't care about how their NS URIs are constructed. ;-)

Sanjay mentioned string length and 'painful'-index as valid concerns; Bob asked "What if the TC does not like the looks of the allocated namespace..."

Summarizing what I said earlier, TCs do tend to care about:

a) hash type, slash type, and simple (no-trailing-delimiter) type
    [choose one of the three, if you're using HTTP scheme]

b) choice of scheme (e.g., HTTP v. URN-based namespaces)

c) path and use of internal "/" chars in an HTTP scheme NS URI

d) selection of a versioning subcomponent identifier substring

etc.

  -rcc

Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: robin@oasis-open.org
Staff bio: http://www.oasis-open.org/who/staff.php#cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783


On Thu, 22 Apr 2010, Marc Goodner wrote:

> If TCs namespaces are generated/assigned in the futures just don't put 
> guids in them and we'll probably all be fine.  :-)
>
> -----Original Message-----
> From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
> Sent: Thursday, April 22, 2010 8:40 AM
> To: Bob Freund; Martin Chapman
> Cc: Mary McRae; chairs@lists.oasis-open.org
> Subject: RE: [chairs] What can Standards Development / TC Administration do to help?
>
>
> Aren't namespaces supposed to be opaque? So unless they are excessively long or practically painful in some other way, the TCs shouldn't care much about their composition, I think.
>
> As far as their uniqueness goes, I think this can be better managed by 
> the authority who owns the domain name (typical component of namespace
> design) and has the overall administrative supervision over the various groups wanting to have their own namespaces.
>
> Basically, Martin's suggestion to have TC's request and get a namespace from the OASIS staff makes sense to me.
>
> Best wishes,
> Sanjay
>
> -----Original Message-----
> From: Bob Freund [mailto:bob.freund@hitachisoftware.com]
> Sent: Thursday, April 22, 2010 8:29 AM
> To: Martin Chapman
> Cc: Mary McRae; chairs@lists.oasis-open.org
> Subject: Re: [chairs] What can Standards Development / TC Administration do to help?
>
> Dosen't that just put the show on the other foot?
> What if the TC does not like the looks of the allocated namespace which might be some random string?
>
> On Apr 22, 2010, at 11:07 AM, Martin Chapman wrote:
>
>> How about having a service whereby TCs can request the allocation of 
>> a
> namespace, rather than making one up and falling foul of the hard to interpret guidelines. This could also be accompanied with a partially filled out rddl document that points to the right places.
>>
>> Martin.
>>
>>> -----Original Message-----
>>> From: Mary McRae [mailto:mary.mcrae@oasis-open.org]
>>> Sent: 21 April 2010 20:27
>>> To: chairs@lists.oasis-open.org
>>> Subject: [chairs] What can Standards Development / TC Administration
> do to help?
>>>
>>> Hi everyone,
>>>
>>>  If you've submitted a specification for public review or CS ballot
> recently, you've probably met
>>> Kim. I'm thrilled to have her on board and hopefully we're now in
> good shape to get your documents
>>> turned around quickly once again.
>>>
>>>  That said, I have at least a dozen ideas of services we can once
> again offer, or new services, to
>>> make your lives a bit easier, but I thought I would ask you for your
> ideas rather than deciding for
>>> you. There are some caveats of course:
>>>
>>> a. Neither Kim nor I have the power or the skillset to change
> anything about the way Kavi works.
>>> b. We're not talking about changes to the TC Process.
>>>
>>> So, for instance:
>>>
>>> - Would you find a template for recording meeting minutes helpful? 
>>> If
> yes, in what flavors?
>>>
>>> - Would you like us to take over creation of spec covers? (as in
> you'll use a temporary cover which
>>> would become part of the template, you would provide us with 
>>> whatever
> information necessary, and we
>>> would create the cover pages with all the appropriate links and make
> sure they work before uploading
>>> to docs.oasis-open.org?)
>>>
>>> - Would you like us to review your specifications prior to TC 
>>> ballots
> so you don't need to go back and
>>> fix stuff afterwards?
>>>
>>> - Would you like us to call in to TC meetings periodically just to
> hear our voices and answer any
>>> questions you might have?
>>>
>>> - Would you like more training materials? If yes, is there a
> particular topic you'd like to see
>>> covered?
>>>
>>> Remember these are just some of *my* ideas; I want to hear *your*
> ideas. I need to know what your TOP
>>> request is; you can have more than one, but please list in order of
> priority. While you're free to
>>> discuss on this list, please send your actual list to me so I can
> track them.
>>>
>>> Thanks!
>>>
>>> Mary
>>>
>>> Mary P McRae
>>> Director, Standards Development
>>> Technical Committee Administrator
>>> OASIS: Advancing open standards for the information society
>>> email: mary.mcrae@oasis-open.org
>>> web: www.oasis-open.org
>>> twitter: @fiberartisan  #oasisopen
>>> phone: 1.603.232.9090
>>>
>>> Standards are like parachutes: they work best when they're open.
>>>
>>>
>>>
>
>
>



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