[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [chairs] Oasis document identifiers - conclusion!
Haha Rob, actually that's exactly the reason I prefer the under_score. It
aids legibility for those who don't need to see the dash but will be
apparent to anyone coding.
Happy either way.
-----Original Message-----
From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]
Sent: Monday, January 13, 2003 10:41 AM
To: 'eddie@ringtailsolutions.com'; 'chairs@lists.oasis-open.org'
Subject: RE: [chairs] Oasis document identifiers - conclusion!
I would prefer to stick with "-" rather than "_". When the filenames are
presented on a web page as hyperlinks and are underlined, you can't
distinguish the "_" from a space character. Not a big deal, I admit - just
a "presentation" preference...
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: Eddie O'Brien [mailto:eddie@ringtailsolutions.com]
> Sent: Monday, January 13, 2003 10: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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC