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


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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

Subject: Re: [dss] Object naming guidelines

At 02:17 PM 9/3/2003 -0400, Tim Moses wrote:

>Colleagues - Here is a first draft of a proposal for naming objects in the
>dss committee.

This is much needed.  Some comments -

0) The OASIS File Naming Document downloads fine at the moment [0], you 
mentioned it was broken earlier.  We're pretty close, but we could be more 
adherent to it, as I point out below.

1) Do you intend version to be preceed with a "v"?  The examples do so, but 
your draft itself isn't named this way.  The OASIS document doesn't use a 
"v", so I'd say skip it.

2) The Requirements Draft (and your "object naming guidelines" draft) don't 
clearly have a "Part" attribute, since they apply to more than just 
"core".  Could "Part" be omitted if not needed? -

3) Instead of "cd" for committee draft, I think "cs" for committee spec is 
the more appropriate term.  This is what SAML, XACML, and the OASIS doc use.

4) "wd", "cd" (or "cs"), and "os" aren't very descriptive.  Looking at 
SAML's guidelines [1], they always use "draft" but differentiate between TC 
drafts (which have consensus) and individual drafts.  The OASIS doc uses 
"draft" and "cs", and then says OASIS will assign the OASIS Standard name, 
so we can't control that.   I think we could follow the OASIS doc, but also 
differentiate between TC and individual drafts:
   "draft" for TC drafts
   "draft-[person's last name]" for individual drafts
   "cs" for committee specs

For example, we have 2 individual protocol schema drafts:

We'd call the requirements (which is a TC draft):

5) The OASIS doc places the "version" after the "object", so the 
requirements would become:

Don't care much one way or the other, but it might be nice to be consistent 
with their doc.

6) I wouldn't mind dropping the "oasis", which would be more consistent 
with the OASIS doc and other TCs, I think.  But this doesn't matter much.

7) OASIS has a URN namespace (see RFC 3121, or [2]).  We are assigned 
"urn:oasis:names:tc:dss".  Here's how SAML and XACML use it for their schemas:


I'm not sure how we want to arrange our schemas.  We have protocols, and we 
also have the time-stamping and requestor identity elements.  Frederick's 
outline of the core document assumes we might have 2 schemas, one for the 
protocols and one for the core elements, so a strawman might be something like:
   urn:oasis:names:tc:dss:1.0:elements  (for time-stamp and 
requestor-identity elements)

8) Is there any point to specifying a URI format, if we have no control 
over it?

9) Once we finalize this, I'll rename and upload our docs, since I think 
that's the editor's job.


[0] http://www.oasis-open.org/spectools/docs/chairs-filenaming-02.html
[2] http://www.oasis-open.org/committees/guidelines.php#namespaces

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