[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [chairs] Oasis document identifiers - conclusion!
All:
There's really no process for making this scheme normative other than my
waving my magic wand (for whatever that's worth) and declaring that this
is what we will all do. That's essentially what I did with the SpecTools
templates. I'm happy to bless anything that you guys can agree on,
assuming that anything you agree to you won't object to being required
to use.
Eduardo (the TAB chair) also suggests that we have the TAB bless it, and
I suppose that that wouldn't hurt either. I'll send it as an FYI to the
Board too, though we probably don't want to ask for their additional
input :-)
Eve: would you please write this up in some sort of semi-formal manner?
Then I'll run it past the the TAB and Board then, assuming no
objections, I'll post it to the web and tell everyone that this is what
we're using.
-Karl
John Messing wrote:
> I think the proposal as formulated and massaged is fine as far as I can see, but we come back to Eve's question as to the proper procedure to take now since "we don't have a clearly defined decision-making authority responsible for this -- unless it's Karl?... and to Phil Griffin's comment that uniform practice among TC's may be hard to monitor or enforce. I guess the upshot is that Eve's proposal as modified seems to be an acceptable recommendation to those who have been participating on this list, subject to any objections that may follow, but I doubt that the Chairs as a group have any collective adoption or enforcement power.
>
> So where does this recommendation go next?
>
> John Messing
> Chair, eNotary TC
>
> ----- Original Message -----
> From: "jkeane" <jik@jkeane.com>
> To: <chairs@lists.oasis-open.org>
> Sent: Monday, January 13, 2003 8:11 AM
> 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>
>
>
--
=================================================================
Karl F. Best
Vice President, OASIS
+1 978.667.5115 x206
karl.best@oasis-open.org http://www.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC