OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

chairs message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [chairs] Oasis document identifiers - conclusion?


I pretty much share all of Eve's sentiments, including an allergy to spaces
in filenames, and avoiding mixed case in the names.

I also prefer the short "-01", "-02", ... sequencing on the documents rather
than dates.  As Eve said, it's worked extremely well in SSTC/SAML and in my
view, if it ain't broke, don't fix it.  At least, I don't think it's
broken...

I prefer her recommended naming conventions.

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: 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>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC