OASIS Naming Directives

Date: January 24, 2012
Version: 1.2
This version: http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives-v1.2.html
Previous version: http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives-v1.1.html
Latest version: http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html

---

Contents

• 1. Introduction
• 2. Definitions
• 3. Name Characters for Files and Directories
• 4. Name Construction Rules for Files and Directories
• 5. Identifiers for Version, Stage, and Revision
• 6. Rules for URIs and Resources
• 7. XML Namespace Identifiers and Namespace Documents
• 8. Notes
• 9. Revision History

---

1. Introduction

This document specifies rules for proper naming, identification, and usage of URI references for documents produced by OASIS Technical Committees. The OASIS Technical Committee Process provides the broader framework for these rules.

2. Definitions

document identifier — an identifier string that corresponds to a stage-specific filename in a cover page document URI, minus the .ext portion of the filename; a document identifier is also used in a page footer

OASIS Library — the official OASIS repository for approved TC work, located at the URI http://docs.oasis-open.org

stage — a stage, also called an approval stage, is a track-specific named level of maturity for Work Products, and includes the pre-track Working Draft stage

TC document repository — a specific document repository assigned to each TC and required as an upload location for contributions, drafts, and Work Products queued for approval.

Version — (capitalized) a major numbered edition of a Work Product developed through a continuous process of authoring, publication, review, and editorial revision, where the approved publication instances correspond to development stages belonging to one "Version".

3. Name Characters for Files and Directories

For any filename or directory/folder name, TCs must use only the sixty-four characters from among alphanumerics [A-Za-z0-9] and the two punctuation characters: "." (PERIOD), and "-" (HYPHEN)" — that is, any upper-case character, lower-case character, Arabic numeral/digit, FULL STOP [decimal 46], and HYPHEN-MINUS [decimal 45].

These name character restrictions must be adhered to for all files/directories associated with approved Work Products and any candidates for TC approval (e.g., Working Drafts). The rules should be followed in all other contexts where OASIS tools and publication venues support the constraints.

The underscore character ("_") may be used in cases where an application (unavoidably) generates this character, but an underscore must never be used in a filename or directory name that is used in a document URI — a primary URI reference published as a document cover page URI (i.e. as required for identification of a Work Product as a whole or a prose Part of a Multi-Part Work Product). The underscore character may be visually confused with SPACE or an underline-effect in some predictable publication contexts.

4. Name Construction Rules for Files and Directories

Name construction rules define how characters may be used to compose names for files and directories, i.e., prescription for the lexical and syntactic structure of names, given the restricted character inventory. Motivations for these constraints include concerns for fidelity of interchange across different file systems, minimizing the risks of common text-processing errors, usability (visual clarity), and other interoperability considerations.

Constraints:

1. TCs may use mixed case (upper case characters mixed with lower case characters) in filenames and directory names, including camel case. TCs should understand that OASIS web servers will respect case-sensitivity, with no accommodation for case-folding.
2. Filenames and directory names must not contain the trademarked names of products, companies, or other corporate entities where the mark is not owned by OASIS.
3. Filenames and directory names must neither begin nor end with a punctuation character (period or hyphen). Similarly, the document identifier portion of a filename must not end with a punctuation character.
4. Filenames and directory names must not contain multiple (2+) consecutive punctuation characters
5. A filename identifying a specific published instance (stage) of a Work Product, used in a required cover page URI, must have the structure:
   
   [WP-abbrev]-[version-id]-[stage-abbrev][revisionNumber].[ext]
   
   Where:
   
   • [WP-abbrev] is a name under TC control matching the agreed-upon Work Product abbreviation
   • [version-id] is a versioning identifier component composed of the single character V OR v (upper- or lower-case), followed by a numeric string matching the rules for Version (e.g., v1.0 OR V1.1)
   • [stage-abbrev] is a stage abbreviation in lower case characters (e.g.: csd, cnd, csprd, cnprd, cs, cn, cos, os)
   • [revisionNumber] is a two-digit number as prescribed below
   • [ext] is a file extension. [Examples: emix-v1.0-csprd01.doc and xrd-v1.1-cs01.xml]
   • the names of tokens in the grammar rule above (and their constrained values) are intended to be identical (names and meaning) to named tokens in the grammar rule for document URIs
6. A single file(name) extension must be used in each filename except for a recognized set of extensionless filenames in common use. File extensions should conform to industry best practice — matching well-known MIME Media Types.
7. A directory must not contain two or more names (filenames or directory names) that differ ONLY in case. For example, a directory must not contain two directories FOO and Foo, nor two files with filenames BAR.txt and bar.txt.
8. Except as approved by the TC Administrator, filenames having special meaning for operating systems or for OASIS server software must not be used in any Work Product. For example, the following are forbidden: index.html, index.htm, and *.cgi.

The name construction rules enumerated above must be followed for files/directories associated with approved Work Products and any candidate work for TC approval (e.g., Working Drafts). They should be followed in all other contexts where OASIS tools and publication venues support these constraints.

Note: The name construction rules enumerated above cover most publication genres for Standards Track Work Products and for many 'Notes' in the Non-Standards Track. The construction rules are slightly different for independently titled (prose) parts in a Multi-Part Work Product, for the Approved Errata drafts and final format versions, and for some presentation (slideset, white paper) formats. Please consult with TC Administration for guidance on proposed identifiers for Multi-Part Work Product parts, for Approved Errata, and for presentation-ware.

5. Identifiers for Version, Stage, and Revision

Filenames and directory names must be used with other naming components to create prescribed URI references (e.g., hyperlinks) for documents and document portions. This section explains the required use of identifiers for Version, Stage, and Revision which are relevant to creation of URI references for resources within a directory hierarchy.

6. Rules for URIs and Resources

This section sets out rules for construction of path elements in document URIs (prescribed naming patterns within URIs as strings), rules for persistence of URIs, for permanence of published OASIS resources, and appropriate selection of URI references for various usage contexts. TC editors need to understand these rules and the required use of identifier components in order to design a hierarchy of directories that will be used in successive stages through the progress of Work Product development and publication.

7. XML Namespace Identifiers and Namespace Documents

OASIS Work Products which formally declare one or more XML namespaces [viz., namespace bindings] must adhere to the terms of the applicable W3C Recommendations (e.g., Namespaces in XML 1.0, Extensible Markup Language (XML) 1.0, XML Schema) and several OASIS rules for construction of URI references and for use of namespace documents where applicable. XML namespace names are owned and managed by individual OASIS TCs, based upon abbreviated TC names, as specified below. Formal declarations of XML namespaces are made using a family of reserved attributes (e.g., xmlns attributes (PrefixedAttName xmlns:[prefix] and DefaultAttName xmlns) and targetNamespace) in XML instances and schemas.

• An XML namespace name identified by an HTTP scheme URI reference must conform to the pattern:

  http://docs.oasis-open.org/[tc-shortname]/ns/xxxx

  Where:

  • "[tc-shortname]" is the official spelling of the TC abbreviation as used in the (Kavi) group and typically in the TC email list URI (e.g., bias in the namespace name http://docs.oasis-open.org/bias/ns/bias-1.0/, owned and managed by the OASIS Biometric Identity Assurance Services (BIAS) Integration TC)
  • "xxxx" is a short string identifying an XML namespace, which should incorporate a versioning subcomponent (e.g., a string like 201011 representing a date or v1.1 representing a version number)
  • "xxxx" may use any of the same sixty-four characters as names for files and directories/folders, plus internal "/", provided that it terminates with the character "/", "#", or an alphanumeric character [A-Za-z0-9].
  • the required substring pattern [tc-shortname]/ns/ was applicable as of 2012-01, but some alternate patterns based upon earlier practice may be grandfathered, if approved by TC Administration

• The pattern specified above for HTTP scheme URIs uses the /ns/ path element in a syntax reserved for identifying non-information resources only. Therefore, no (file-system) regular files, directories/folders, or symbolic links matching information resources may make use of these URI strings for resource identification.

• Non-information resources using identifiers associated with XML namespaces may be based upon any HTTP scheme URI XML namespace declared by the TC (i.e., identifiers for named properties, functions, dialects, faults, actions, or any named message types). Example: see the Link Relations URIs in one of the CMIS v1.0 XML namespace documents (e.g., http://docs.oasis-open.org/ns/cmis/link/200908/allowableactions, http://docs.oasis-open.org/ns/cmis/link/200908/policies).

• Any HTTP scheme URI matching the base pattern of a declared XML namespace, when dereferenced, will resolve under DNS+HTTP to (fetch) the corresponding namespace document which documents the namespace and the specification which formally declares it. OASIS TC Administration maintains the namespace documents in consultation with TC specification editors.

• URN-based XML namespaces may be declared by existing TCs that have already used this feature, or by associated Maintenance Activity TCs, where architectural considerations require continued use of URNs. URN-based XML namespaces must not be declared otherwise, since they lack a standard, ubiquitous resolution method using DNS[+HTTP]. In URNs, the colon (":") character is expected.

• TCs must define a namespace versioning policy for any XML namespace declared in a specification, and must communicate the text expressing such policy to the TC Administrator for incorporation into the appropriate namespace document.

8. Notes

This reference section is intended to provide details (exceptional cases, etc). For definitions that may provide useful clarification, see Definitions.

• Filenames without extensions. Exceptions to the rule that every filename much include a file extension include: CATALOG or catalog, README, ChangeLog. Please contact the TC Administrator if you wish to recommend additional filenames for consideration.

• Information resource and non-information resource. The term (non-)information resource (mentioned above) is sometimes used to distinguish [1] computer-managed (serializable, textual or binary) objects like document files, image files, video files from [2] physical objects like cars and human persons, or abstract concepts like "smooth". While the two terms are not universally accepted, they offer a convenient way to distinguish documents from XML namespaces. Since an XML namespace is an abstract space of names (possibly unbounded) identified by a URI reference, it is often considered a non-information resource.

• Member-only URIs vs. public URIs. The Kavi collaboration tool [as of 2010-10] creates a private OASIS member-only URI for most resources, and while these private URI references "work" for OASIS members who are logged in, they are broken for all other users, and give the appearance of OASIS-private resources that are not available to the public. Since that outcome frustrates/annoys users and creates a negative/false impression about the "openness" of OASIS, TC members are urged to ensure that the public form of any URI reference is cited in all communications and documents under their control.

• Work Product title/name. A document title, also called a Work Product name, (e.g., TC Process Sections 2.18 and 2.19), should be composed from a suitable identifier followed immediately (without intervening punctuation) by the word "Version" and the Version number. The title of a Work Product must not include any trademarks or service marks not owned by OASIS. Any acronyms in the title should be spelled out, but full spelling is not required. When formatted for display, the complete title should be treated as though it is a single line of text.

  Please consult with TC Administration on proposed use of punctuation characters in a Work Product title. In most cases, use of COLON or FULL STOP (PERIOD) would be acceptable, as would be PAREN chars, a needed. Use of "hyphen" to mark juncture between title components is to be avoided: by "hyphen" we mean the HYPHEN-MINUS character (decimal 45, U+002D) and any character that looks like HYPHEN-MINUS from a distance. HYPHEN-MINUS is often confused with other characters having similar visual appearance, some of which interfere with search, display, and other text processing functions in various contexts (e.g., U+2212 minus; U+2010 hyphen; U+00AD soft hyphen; U+2011 non-breaking hyphen; U+2043 hyphen bullet; U+2012 figure dash; U+2013 en dash; U+2014 em dash; U+2015 horizontal bar; several hyphens-like characters in non-Latin scripts). The character HYPHEN-MINUS is permissible in a Work Product title when used within hyphenated words/terms (e.g., "Event-Driven").

• Scope. The naming directives in this document (especially for name characters and construction) are intended to apply broadly to all official OASIS publication venues that support rule compliance, including the OASIS Library, TC document repository, email list archives (file attachments), Wikis, SVN (Subversion) repository instances, JIRA issues tracking facilities, TC/SC web sites, Member Section web sites, etc. For a partial list of URIs identifying OASIS Online Tools, see:

  • OASIS Wiki List, and example XACML TC Wiki
  • SVN (Subversion) Repositories, and example SCA-Assemby TC SVN Repository
  • JIRA Issues Tracker, and example Office/OpenDocument TC Issues Tracking

• TC document repository. With a few approved exceptions (e.g., TC meeting minutes published to the general mailing list), the TC Process requires that work produced by TC Members must be uploaded to "the TC's document repository" in the appropriate folder(s). This fulfills the TC Process requirement "Editable formats of all versions of TC documents must be delivered to the TC's document repository" (2.18 (4)). TC Members should understand that content uploaded to the TC document repository and approved for official publication will be QC'd and then installed in the OASIS Library by the TC Administrator.

  Each OASIS TC is assigned a "document repository" (as of 2010-10) through the Kavi collaboration suite. For example, in the case of the OASIS Provisioning Services TC, a publicly accessible link to the TC's document repository is: http://www.oasis-open.org/committees/documents.php?wg_abbrev=provision. TC members upload files to that repository through the [Kavi] "TC Members Page" by navigating to the Documents area, locating the appropriate Folder, and clicking the button for "Add New Document" in that Folder.

• Track. TC members should take into account various options for document development and approval through a life-cycle suitable for any particular deliverable. The OASIS Technical Committee Process effective October 15, 2010 introduced a two-track system for OASIS Work Products, so that a Work Product was classified as either a Standards Track Work Product or a Non-Standards Track Work Product. Whereas Standards Track Work Products are typically designed for implementation, Non-Standards Track Work Products are typically represented by TC-approved white papers, slide presentations, and other material used for educational or promotional purposes. The review and approval processes for Work Products in the two tracks are (almost) identical, as are most rules for the creation of document identifiers, required file formats, etc.

  A Standards Track Work Product, intended as an implementation specification, contains a required set of numbered conformance clauses and has Normative References. A Non-Standards Track Work Product does not contain normative statements that define mandatory conformance requirements. It may not be submitted for approval by the Consortium membership as an OASIS Standard, and the patent provisions of the OASIS IPR Policy (under a TC's chosen IPR Mode) do not apply.

---

9. Revision History

This document is revised from time to time in order to supply additional examples, correct typos, and improve clarity; such revisions do not motivate the creation of a new version. Any substantive change that alters a rule is noted in this section, and every attempt will be made to honor naming decisions made by TCs that conform to rules so revised.

• Version 1.2 Date: January 24, 2012. A single rule change was made with respect to the required pattern for XML namespace name construction: it is now http://docs.oasis-open.org/[tc-shortname]/ns/xxxx, modulo grandfathered allowance of earlier practice, when approved by TC Administration. Other changes are simply non-rule clarifications and additional examples.

• Version 1.1 Date: January 28, 2011. A one-character adjustment was made in the rule for composing instance-specific filenames, to reflect what had become common practice already in 2010: the pattern [WP-abbrev]-[version-id] (with HYPHEN separator) rather than [WP-abbrev][version-id]. Thus the revised rule requires, e.g., OpenDocument-v1.2 rather than OpenDocumentv1.2 in the stage/instance-specific filename.

• Version 1.0 Date: October 14, 2010. Initial release.

---

Feedback: Please send questions or comments on this document to robin@oasis-open.org.