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

Trevor - Good feedback.  I'll update the document with the non-contentious
points and wait for discussion of any contentious ones.

- The new OASIS Procedure changes the name from Committee Specification to
Committee Draft.

- Let's leave out the "v".

- I agree, anything that is applicable across the whole of the TC's
activities should omit the "part" component.

- Do people want to drop 'oasis'?

- I personally prefer placing 'version' closer to the root.  This leads to
grouping of documents by the major version of the standard, rather than by
type of document for all versions.  What do others want?

- In the interests of brevity, I don't mind the abbreviation 'wd'.  What do
other want?

- You are right, I haven't taken account of different kinds of draft: those
that are recognized as committee drafts and those that are simply
contributions.  We should deal with that.

- Do we want to use URNs?  I am hoping (perhaps with little justification)
that OASIS will solve the problem of names that cannot be dereferenced to
the object.  If this happens, then we would want to have names that look
like URLs.  If it doesn't happen, then names that are URLs look pretty

All the best.  Tim.

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: Thursday, September 04, 2003 3:53 PM
To: Tim Moses; 'DSS'
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


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