[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [chairs] Unique OASIS document identifiers
In the process of consulting the last
draft of Eve's Proposed Draft of "Rules for OASIS Document File Naming" (Working
Draft 01, 5 February 2003) I had a chance to look back on the
draft and prior discussions. We all
owe
Eve a debt of gratitude for such
professional work.
As I re-read it in the context of
how to name one of our documents, I had some very minor final points and a
question about how we can button this up. I also encountered some
anomalies on the archives.
ARCHIVES
As I worked on it to formulate some
filenames, I wanted to check back on the discussion, BUT
they appeared under three
threads.
1) At long last, filenaming rules
document
2) Oasis document identifiers -
conclusion?
3) Unique OASIS document
identifiers
I'm posting this under "Unique OASIS Document Identifiers" as
the earliest and the most durable
sounding thread, and one that needs
closure as well. It is also a reminder that
we should consistently use the same title, and use informative and more
formal titles for the public who may review our
archives.
Other anomalies: Nothing came
up in a search for "Eve," which I recall is in the From field and in the text
too. A search fore items using the filter "This year" and "This
month" only returned items from 2002. Does something have to be
reset? Searching for "this eList" returned 0.
FINAL NITS ON
PROPOSAL
Anyways, I had a few very
minor points and questions based on trying to name a
document.
3.1. Second Bullet - "Lowercase
spelling is recommended"
Why? Some of
our groups have grand discussions on camelCase and UpperCamel case. e.g
LegalXML and OdrXML are official title from their charters. Mixed
case reads better than legalxm or odrxml. And, hey,
maybe I am just a case sensitive kind of guy ;-)
I don't see
any need for this recommendation and, unless there is
a cogent technical reason, suggest deleting the thought in the
final version.
The following rules apply to all documents:
Didn't we
retire underbars in the the last discussion? With a poll? We should
either discourage underbars or also be silent on this point.
3.4 "cs for
Committee Specifications" Isn't this acronym a bit cryptic? And contrary to
the no cryptic acronym policy in the introduction.
A.
Notices
Curiosity: What is the source of the language in this
notice? From the OASIS lawyer? Are we supposed to have that in all documents?
Speaking as a lawyer, can the language be simplified?
CLOSURE
AND -
how can we bring this to closure? Do we vote? Consensus? Formal Adoption by the
Board? LegalXML has a steering committee next Tuesday and I would like to report
this is done.
All the
best,
Jim
Keane
Co-Chair,
OdrXML TC
Vice-Chair,
LegalXML Member Section
PS.
Eve, Thanks
for using OdrXML so much, but maybe the examples should cover other TC's as
well. I did appreciate "odiousxml." Nice... And to the point, you really do a
doubletake without mixed case.
JKeane.Law.Pro
North Potomac MD 20878
-----Original Message-----
From: Eve L. Maler [mailto:eve.maler@sun.com] Sent: Tuesday, February 11, 2003 1:04 PM To: 'chairs@lists.oasis-open.org' Subject: [chairs] At long last, filenaming rules document Working Draft 01, 5 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. [@@ Do people agree? SAML had a revision to its CSs, and nothing in the OASIS process prevents frequent Committee Specification approvals.] 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). [@@ Should extended descriptions be allowed here? Would change-bar forms of OASIS Standard documents be expected?] 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]