[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [chairs] Oasis document identifiers - conclusion!
Oh please make it hyphens!
Ciao,
Rex
At 5:16 PM -0500 1/13/03, jkeane wrote:
>Hyphens winning by large margin.
>Any more underscore fans?
>
>James I. Keane
>JKeane.Law.Pro
>20 Esworthy Terrace
>North Potomac MD 20878
>301-948-4062 F: 301-947-1176 (N.B.: NEW FAX NUMBER)
>www.jkeane.com <http://www.jkeane.com>
>
>Co-Author and Annual Update Editor of Treatise: Litigation Support Systems,
>An Attorney Guide 2nd
><http://www.westgroup.com/store/product.asp?product_id=16989703&catalog_name
>=wgstore> Ed. (WestGroup, 1992, updated through 2002)
>
>
>-----Original Message-----
>From: Drummond Reed [mailto:Drummond.Reed@onename.com]
>Sent: Monday, January 13, 2003 11:33 AM
>To: chairs@lists.oasis-open.org
>Subject: RE: [chairs] Oasis document identifiers - conclusion!
>
>
>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>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
--
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC