[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue with using dates in the document names
I've attached the last version of Eve's document re: naming guidelines that was distributed on the TC chairs list. Note that Eduardo Gutentag had proposed some minor additional changes (not relevant to the current discussion), but there wasn't final agreement on those.
Anyway, these guidelines do provide some flexibility in file names for a TC's outputs (drafts or committee drafts). This includes the possibility of including a date encoded in the name. TC outputs are described in section 3.4. Specifically: tcid-description-version-draft-revision[-extdesc].ext and tcid-description-version-cs[-revision][-extdesc].ext
[I assume the italicized components won't show up for some folks receiving this message, so refer to the attachment.] Note the example: odrxml-protocol-1.0-draft-17-20030214.html does include a date in the -extdesc component. IMO, however, it was not the intent of the guidelines to use a date in the -description component of the name.
However, the guidelines for "approved OASIS Standard" filenames do not appear to provide this same flexibility. See section 3.5. The format is simply: oasis-oasisnumber-tcid-description-version.ext
I believe the intent is to distinguish releases of the TC outputs (spec's and schemas) by their version, not by date. For example: oasis-1234-odrxml-core-1.0.pdf and oasis-1236-ordxml-protocol-schema-1.0.xsd
So while we can choose to embed dates in the filenames for our drafts and committee drafts, they won't comply with the guidelines if/when they are adopted as OASIS standards.
I mention this now since we might want to take it into account when developing the URL components following the TC name in the proposal from OASIS (www.docs.oasis-open.org/<tcname>/<docname>). Personally, I don't see the need for a date component, but I'm not going to object if others have reasons for wanting them.
Also, it should be obvious from the above discussion, but the filenames will definitely change between our final committee drafts and any approved OASIS standard version of the documents.
Rob Philpott
|
Working Draft 02, 18 February 2003
Copyright © 2003 OASIS Open, Inc. All Rights Reserved. Table of Contents
AppendixesThe community of OASIS TC chairs (archive) has agreed on a set of file naming rules for TC charters, contributions made to TCs, TC drafts and Committee Specifications, and OASIS Standards. We are recommending to the TAB and the OASIS Board that these rules be adopted formally. The rules adhere to the following general principles:
Informal documents produced by a TC that are not on at least a Committee Specification track (such as white papers and presentation slides) are not in the scope of these rules. The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC 2119]. The file naming rules in this document use the following special terms and concepts:
The following sections provide the proposed file naming rules for OASIS documents. The following rules apply to all documents:
Below, examples for hypothetical documents produced by the Online Dispute Resolution TC (TC identifier odrxml) are provided for each set of rules. TC charters must use the following file naming rule. The TC may choose its own version numbering scheme. tcid-charter-version[-revision][-extdesc].ext
Contributions must use the following file naming rule. It is recommended to use the primary author's family name or surname as the contributor ID. The contributors may choose their own description field and extended description field. contributorid-description[-revision][-extdesc].ext
TC outputs must use one of the following two file naming rules. The TC may choose its own description field, extended description field, and version numbering scheme. A keyword is used to indicate the document stage: either draft for working drafts or cs for Committee Specifications. The revision field is optional for Committee Specifications, depending on whether the TC expects to make minor revisions to essentially stable drafts in response to the public review period. The extended description field may be used to provide the publication date, but it is recommended not to do this for Committee Specifications. tcid-description-version-draft-revision[-extdesc].ext tcid-description-version-cs[-revision][-extdesc].ext
OASIS Standard documents must use the following file naming rule. The OASIS staff is responsible for assigning the OASIS number. The number is unique across all OASIS Standard documents in all versions and revisions (but not all forms). oasis-oasisnumber-tcid-description-version.ext
A. NoticesCopyright © The Organization for the Advancement of Structured Information Standards [OASIS] 2001–2003. All Rights Reserved. OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director. OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS has been notified of intellectual property rights claimed in regard to some or all of the contents of this specification. For more information consult the online list of claimed rights. Normative[RFC 2119] S. Bradner. RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. IETF (Internet Engineering Task Force). 1997. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]