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!


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>



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


Powered by eList eXpress LLC