Re: [chairs] Oasis document identifiers - conclusion?

["Eve L. Maler" <eve.maler@sun.com>]

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