[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [chairs] Oasis document identifiers - conclusion!
I think also that hyphens are better because of the possible difficulty with hyperlinked references to names that have underscores. ---------- Original Message ---------------------------------- From: Drummond Reed <Drummond.Reed@onename.com> Date: Mon, 13 Jan 2003 08:32:39 -0800 >Ironic, I recently switched to hyphens from underscores because the former >is more widely acceptable in URLs (for example, hyphens are legal in DNS >names.) It's also easier to tell they are there when the address is turned >into a hyperlink - frequently underscores are obscured by the hyperlink >underline. > >But I can live with either too. > >=Drummond > >-----Original Message----- >From: Eddie O'Brien [mailto:eddie@ringtailsolutions.com] >Sent: Monday, January 13, 2003 7:23 AM >To: chairs@lists.oasis-open.org >Subject: RE: [chairs] Oasis document identifiers - conclusion! > >I've been following the conversation and my only preference would be a >programmatic preference: > >oasis_####_odrxml_blah_1.0.html > >rather than.... > >oasis-####-odrxml-blah-1.0.html > >People who write code for living will understand the point, I also think its >more visually legible, but I can live with either. > >Regards > >Eddie O'Brien > >-----Original Message----- >From: jkeane [mailto:jik@jkeane.com] >Sent: Monday, January 13, 2003 10:12 AM >To: chairs@lists.oasis-open.org >Subject: RE: [chairs] Oasis document identifiers - conclusion! > > >Can any NOT live with this approach to document identifiers? > > >James I. Keane >OdrXML, LegalXML Steering Committee > > > >-----Original Message----- >From: Daniel Greenwood [mailto:dang@mit.edu] >Sent: Sunday, January 12, 2003 11:52 PM >To: Philpott, Robert; chairs@lists.oasis-open.org >Subject: RE: [chairs] Oasis document identifiers - conclusion! > > >Ah, yes, that is right - I went too fast - thanks for catching that. > >Then would the final proposal be as follows: > >OASIS Standard stage: > oasis-####-odrxml-blah-1.0.html > oasis-####-odrxml-blah-1.0.pdf >Committee Spec stage: > odrxml-blah-1.0-cs.html > odrxml-blah-1.0-cs.pdf > odrxml-lala-1.0-cs.html > odrxml-lala-1.0-cs.pdf >Working Drafts stage: > odrxml-blah-1.0-draft-03.html > odrxml-blah-1.0-draft-03-diff.html > odrxml-blah-1.0-draft-02.html > odrxml-blah-1.0-draft-02-diff.html > odrxml-blah-1.0-draft-01.html > odrxml-lala-1.0-draft-03.html > odrxml-lala-1.0-draft-03-diff.html > odrxml-lala-1.0-draft-02.html > odrxml-lala-1.0-draft-02-diff.html > odrxml-lala-1.0-draft-01.html >OASIS TC Formation stage: > odrxml-charter-1.0.html > >Thanks, > - Dan, eContracts TC > >============================================== >| Daniel J. Greenwood, Esq. >| Director, E-Commerce Architecture Program >| MIT School of Architecture and Planning >| 77 Massachusetts Avenue, Room 7-231 >| Cambridge, MA 02139 >| http://ecitizen.mit.edu >| or http://www.civics.com >| dang@mit.edu >============================================== > >-----Original Message----- >From: Philpott, Robert [mailto:rphilpott@rsasecurity.com] >Sent: Sunday, January 12, 2003 11:33 PM >To: 'dang@mit.edu'; 'chairs@lists.oasis-open.org' >Subject: RE: [chairs] Oasis document identifiers - conclusion! > >Dan - I think you missed a nuance of Eve's recommendation. You also did not >factor in the OASIS-approved document number in your examples. Was that >intentional? which has been discussed on the list. Eve did not include a >"-os" for oasis-approved standard. For those docs, the oasis-approved >document ID gets prepended to the file name with an "oasis-" label. > >> OASIS Standard stage: >> oasis-####-odrxml-charter-1.0.doc >> oasis-####-odrxml-charter-1.0.pdf > >I actually prefer this over the "-os" suggestion since it makes a clear >distinction between draft or cs specs and final approved standards. Also, >"os" and "cs" look a bit too much alike and may cause confusion. > >Rob Philpott >RSA Security Inc. >The Most Trusted Name in e-Security >Tel: 781-515-7115 >Mobile: 617-510-0893 >Fax: 781-515-7020 >mailto:rphilpott@rsasecurity.com > > >> -----Original Message----- >> From: Daniel Greenwood [mailto:dang@mit.edu] >> Sent: Sunday, January 12, 2003 11:24 PM >> To: Eve L. Maler; chairs@lists.oasis-open.org >> Subject: RE: [chairs] Oasis document identifiers - conclusion! >> >> I am also in complete agreement with Eve's proposal. >> >> Just to be sure we're all on the same page, and the proposal is >> complete, I have assumed that this naming scheme is intended to >> include final Oasis Standards (which I further assume should be >> denoted as "os"). I scratched out a fuller example below (primarily >> to illustrate to my own satisfaction how this would actually play >> out), which I share to see if it is correct. >> >> I have further assumed that there would be no "-diff" designations >for >> official Oasis Standards or Technical Committee Specifications - >> because they are in fact "final" stand alone documents. But I have >> applied the "-diff" suffix to draft documents (including draft >> spec/standards), different where versions of the same document must >be >> dealt with, and a "red-lined" version to show changes is helpful. >> >> Along the same lines, I don't understand the need for any additional >> trailing version information after a "cs" or "os" document, as those >> designations mean the document has already been voted upon by OASIS >or >> agreed upon by the TC and is final in THAT form. A later final >> official version of an earlier final official standard or >> specification would be, I presume, "2.0" rather than "1.0". So, I >> have removed the additional versioning information from the "os" and >> "cs" documents. Is this not correct? >> >> I've played out the naming scheme with two official documents: >"blah" >> and "lala". Blah goes on "all the way" to become an OASIS Standard >> (os), while the "lala" document plateaus as a Technical Committee >> Specification (cs). There are drafts of both "blah" and "lala". Since >> there is, technically, no TC before a final charter exists, I have not >> bothered to apply a version chain to earlier drafts of a charter >> document (though individuals forming a TC certainly may wish to use >> the same convention) and I have called that phase the "TC Formation >> stage" rather than "standard stage" to be clearer about >what >> has actually happened. After the TC is formed, then the standards >> creation work begins during the "wording drafts" phase. >> >> OASIS Standard stage: >> odrxml-blah-1.0-os.html >> odrxml-blah-1.0-os.pdf >> Committee Spec stage: >> odrxml-blah-1.0-cs.html >> odrxml-blah-1.0-cs.pdf >> odrxml-lala-1.0-cs.html >> odrxml-lala-1.0-cs.pdf >> Working drafts: >> odrxml-blah-1.0-draft-03.html >> odrxml-blah-1.0-draft-03-diff.html >> odrxml-blah-1.0-draft-02.html >> odrxml-blah-1.0-draft-02-diff.html >> odrxml-blah-1.0-draft-01.html >> odrxml-lala-1.0-draft-03.html >> odrxml-lala-1.0-draft-03-diff.html >> odrxml-lala-1.0-draft-02.html >> odrxml-lala-1.0-draft-02-diff.html >> odrxml-lala-1.0-draft-01.html >> OASIS TC formation stage: >> odrxml-charter-1.0.html >> >> A final note - I believe it is very important that any final >agreement >> on semantic naming schemes include the "cs" phase as a separate >> designation, and not simply the "draft" or "os" phases. >> >> I wonder: is the above "blah" and "lala" example a correct (or at >> least acceptable) extrapolation of how the proposal would be >applied? >> >> Thanks, >> - Dan Greenwood, Chair of the eContracts TC >> >> ============================================== >> | Daniel J. Greenwood, Esq. >> | Director, E-Commerce Architecture Program >> | MIT School of Architecture and Planning >> | 77 Massachusetts Avenue, Room 7-231 >> | Cambridge, MA 02139 >> | http://ecitizen.mit.edu >> | or http://www.civics.com >> | dang@mit.edu >> ============================================== >> >> -----Original Message----- >> From: Eve L. Maler [mailto:eve.maler@sun.com] >> Sent: Sunday, January 12, 2003 10:34 PM >> To: chairs@lists.oasis-open.org >> Subject: Re: [chairs] Oasis document identifiers - conclusion? >> >> I'm sure the Kavi system will be wonderful and I agree that having >> proper metadata is the right thing to do, but it very much appeals >to >> me >> to have a filenaming convention that works even when all you have is >> text editors, file directories, and browsers, with no cool >> registry/repository in the middle. The web earned its success by >> working even in "roughing-it" circumstances, and I think we'll >benefit >> by continuing to account for them. >> >> jkeane wrote: >> > 1) Have a meaningful name - no acronyms or abbreviations for >> contents. >> > Short TC names do makes sense. I keep an archive of work >products, >> pruning >> > out unnecessary documents and most drafts after the project is >long >> over. >> > When you are browsing an older directory the Alzheimer effect >kicks >> in after >> > six months. >> >> Certainly it makes sense to avoid being cryptic. However, I notice >> that the current OASIS web server seems to truncate long filenames >> when doing >> a directory display, losing critical information unless you hover >over >> the link and observe the full link name in the browser footer bar. Can >> this truncation be fixed? >> >> > 2) We store related documents in project sub-directories. This >> makes it >> > unnecessary to include extensive generic info in every file name. >> If you >> > store all the docs in a single directory, it would make more sense >> to have >> > the prime sort by TC name. >> >> I was thinking that all the filenames of all the TC outputs should >be >> distinguishable and unique even if they were put into one big pile. >> Thus, the TC ID should always appear in the filename because it >serves >> as a "namespace" that disambiguates otherwise-similar filenames from >> different groups. Project subdirectories are great if called for, >but >> I'd think it would still be desirable to reflect those categories in >> their filenames. >> >> > >> > 3) Include the date (as proposed, but in a sortable format) File >> dates >> > change (i.e. moving all files from computer A to computer B for >> maintenance. >> >> Yikes, I really hate putting publication dates in filenames. W3C >does >> that, and it's a really unwieldy and hard-to-mentally-sort device. >In >> the SAML group, we've just been using the trick of publishing 00, >01, >> 02, 03, etc. drafts, and I've been advocating it here because it has >> worked incredibly well. That way, implementors can say "Our latest >> download conforms to draft 31, but we're prepared to change it to >> reflect the draft-34 changes by next Wednesday." And in a meeting >you >> can say "I move to accept draft 07 of this document as a Committee >> Spec." The constantly increasing draft number gives more >information >> at >> a glance than does the (frankly random) date on which publication >> occurred, and is way shorter. >> >> > 4) Include version sequence in sortable format. This will avoid >> confusion >> > about which drafts are on the table. >> >> Agree. Though so far we've been discussing allowing the >{description} >> field to be anything the TC wants, so one way to go is to make >> recommendations (SHOULDs) about this, and another is to make fast >> rules >> (MUSTs) about it. >> >> > 5) Add any relevant trailing info about status or special >features. >> >> Sure. >> >> > Here is an example of what we used in drafting the Online Dispute >> Resolution >> > Charter. This approach has enabled me to work with ad hoc teams >over >> many >> > projects over many years and not have too much confusion or >spending >> time in >> > discussions (which we needed do here) like this. >> > >> > OdrXML Charter 1.0 DRAFT 2002.09.26.doc >> > OdrXML Charter 1.1 DRAFT 2002.10.07.doc >> > OdrXML Charter 1.2 DRAFT FINAL 2002.10.18.doc >> > OdrXML Charter 1.2 DRAFT FINAL REDLINE 2002.10.18.doc OdrXML Charter >> > 1.2a DRAFT FINAL 2002.10.19.doc OdrXML Charter FINAL 2002.11.11.doc >> >> Exposing my weirdnesses once again, I have an allergy to spaces in >> filenames. Most systems and software handle them now, but a few old >> ones don't handle them so well. >> >> I do agree with your ordering of the fields, though. >> >> My preferences (including lowercase spelling :-) mapped onto your >> ordering would look (very) approximately like this: >> >> Working drafts: >> odrxml-charter-1.0-draft-01.doc >> odrxml-charter-1.0-draft-02.doc >> odrxml-charter-1.0-draft-03.doc >> Committee Spec stage: >> odrxml-charter-1.0-cs-01.doc >> odrxml-charter-1.0-cs-01-diff.doc >> odrxml-charter-1.0-cs-01.pdf >> OASIS Standard stage: >> oasis-####-odrxml-charter-1.0.doc >> oasis-####-odrxml-charter-1.0.pdf >> >> I would like to come to closure on this matter really soon because I >> don't have a lot more cycles to spend on it, but the problem is that >> we don't have a clearly defined decision-making authority responsible >for >> this -- unless it's Karl?... >> >> Eve >> >> -- >> Eve Maler +1 781 442 3190 >> Sun Microsystems cell +1 781 354 9441 >> Web Technologies and Standards eve.maler @ sun.com >> >> >> ---------------------------------------------------------------- >> To subscribe or unsubscribe from this elist use the subscription >> manager: <http://lists.oasis-open.org/ob/adm.pl> >> >> >> ---------------------------------------------------------------- >> To subscribe or unsubscribe from this elist use the subscription >> manager: <http://lists.oasis-open.org/ob/adm.pl> > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC