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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: "tc" vs. "specification"


Hello UBL TC,

The question arose with regard to the SBS whether the OSIS RFC
3132 URN document class identifier field changes from "tc" to
"specification" (a) when the document goes from "Committee Draft"
to "Committee Specification" or (b) when the document goes from
"Committee Specification" to "OASIS Standard."  The relevant
section of RFC 3132 reads as follows:

/=================================================================
| The Names Hierarchy
| 
|       The NSS in the names hierarchy begins with a document class
|       identifier.  There are three classes of identifiers:
| 
|       "specification", "tc", and "technical".
| 
|       Specifications
| 
|          The "specification" hierarchy is for OASIS Specifications.  The
|          general structure of the NSS in the specification hierarchy has
|          the form:
| 
|             urn:oasis:names:specification:{specification-id}
|                            :{type}{:subtype}?:{document-id}
| 
|          where "specification-id" is a unique identifier for the
|          specification, "type" identifies the document type (document,
|          schema, stylesheet, entity, xmlns, etc.), the optional
|          "subtype" provides additional information about the document
|          type (for example, stylesheet or schema language), and
|          "document-id" is a unique identifier for the document.
| 
|          The Director of Technical Operations at OASIS assigns document
|          types, subtypes, and all unique identifiers.
| 
|       Technical Committee Work Products
| 
|          The "tc" hierarchy is for work products of OASIS Technical
|          Committees.  The general structure of the NSS in the tc
|          hierarchy has the form:
| 
|             urn:oasis:names:tc:{tc-id}:{type}{:subtype}?:{document-id}
| 
|          where "tc-id" is a unique identifier for the Technical
|          Committee, and the remaining fields are assigned as per the
|          specification hierarchy.
| 
|       Technical Papers
| 
|          The "technical" hierarchy identifies legacy documents
|          (Technical Notes, Resolutions, Memoranda, and Research Papers).
|          The general structure of the NSS in the "technical" hierarchies
|          has the form:
| 
|             urn:oasis:names:technical:{document-type}
|                            :{document-id}:{amendment-id}
| 
|          The document type is one of the following: "note",
|          "resolution", "memorandum", or "researchpaper".
| 
|          The document and amendment identifiers are derived from the
|          legacy system for naming these documents.  The document
|          identifier consists of a two digit year and a sequential
|          number, the amendment identifier is the year of the amendment.
\=================================================================

Based on this passage, it's my finding that despite the word
"specification," an OASIS Committee Specification is still the
"work product of an OASIS technical committee" (having received no
further endorsement from OASIS as an organization) and therefore
would retain the "tc" in its document class identifier, changing
to "[OASIS] specification" only if and when through the process of
OASIS standardization it becomes a product of OASIS itself.  This
being the case, we can keep the URN the same as the document makes
its transition from Committee Draft to Committee Specification.

If anyone knows of an OASIS decision that would contradict this
finding, please let us know.

Jon



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