[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: File naming conventions
Dear chairs, In April, the TAB voted on the proposed file naming mechanism presented by the TC chairs. The result of the vote was: - 2 abstentions - 5 yes - 3 conditional yes The conditional votes asked that three questions about the recommendation be addressed: 1. The document states there is no distinction between normative and non-normative outputs from the TC process. Yet there is certainly a meaningful distinction between the two in practice. We would prefer that the document either a) remove this statement and leave implicit the expectation that any TC outputs would adhere to the recommendation, or b) clarify the distinction between normative and non-normative output and explicitly state the expectation that normative TC outputs would adhere to the recommendation. 2. The example in 3.3/Contributions does not appear to follow the rule it illustrates. The rule says "contributorid - description" but the examples show tcid-contribid-description. It seems that either the rule or the example should be corrected. 3. Where the TC *may* choose its own version numbering etc., we suggest that the recommendation be amended to say something like "using a scheme that fulfills the general principles of the recommendation." (In other words, a scheme that still lets things sort, etc.) Would the TC's please review and respond to these questions? Once they have been addressed, we believe the TAB is ready to advise the Board to adopt these as Chairs- and TAB-approved best practices for all OASIS TCs. In order to expedite this process, (and knowing that the original editor of the document could not deal with it at the moment) I have taken the liberty of providing a revision of the HTML version of the document (unfortunately I could not find the XML version where I would had thought it was supposed to be). I have marked additions in green font, and deletions in red overstrike. The modifications I propose in this revised HTML version are: 1) a sentence regarding adherence to the rules in the case of normative output 2) a deletion of tcid in the examples 3) a sentence regarding adherence to the spirit of the recommendation If the chairs agree to the recommendations of the TAB, and the suggestions to be found in the attached file, then we can proceed. Otherwise the TAB will wait until a new version is presented to it. -- Eduardo Gutentag | e-mail: eduardo.gutentag@Sun.COM Web Technologies and Standards | Phone: +1 510 550 4616 x31442 Sun Microsystems Inc. | 1800 Harrison St. Oakland, CA 94612 W3C AC Rep / OASIS TAB ChairTitle: Proposed Rules for OASIS Document File Naming
Proposed Rules for OASIS Document File NamingWorking Draft 02, 18 February 2003
Copyright © 2003 OASIS Open, Inc. All Rights Reserved. Table of Contents
Appendixes1. IntroductionThe 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. 2. Terms and ConceptsThe 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:
Note
3. File Naming RulesThe following sections provide the proposed file naming rules for OASIS documents. 3.1. General RulesThe 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. 3.2. Rules for ChartersTC charters must use the following file naming rule. The TC may choose its own version numbering scheme. tcid-charter-version[-revision][-extdesc].ext
3.3. Rules for ContributionsContributions 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
3.4. Rules for TC OutputsTC 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 as long as the scheme used fulfills the general principles of this recommendation (that is, allows for sorting, etc.). 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
3.5. Rules for OASIS StandardsOASIS 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. B. Revision History
ReferencesNormative[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]