RE: [chairs] File naming conventions

[jkeane <jik@jkeane.com>]

A Nit:

Section 3.2.  "A change-bar form of afirst draft of a clarified charter."

separate the "a" from "first"

I have no recollection of encountering the term "change-bar."  Lawyers
commonly use the term "redline" for exchanging revision to legal documents.
Is that the same? Is "redline" more common?  In England they "blueline."

ERRATA
The issue of errata has two branches, one is the attachment of an errata
sheet that does not change the original. Court Reporters will issue an
errata sheet after a party reviews a transcript, rather than re-issue 100's
of pages of material.  The other is a fix in text, which might correct a
substantive error or a non-substantive one.  The later is sometimes called
the scrivener's error. My nit of "afirst" from above counts as scrivener's
error.  The other is an error like leaving out the word "NO" even though
everyone agreed to say NO.  That may well warrant a new version, so there is
simply no question.

In my own work I've used small letters to signify non-substantive changes
during document exchanges with a shared document. e.g. We draft a contract
and both redline it. You can be blue. And agree. When I go to accept the
changes, which I call version final draft 1.0, which I send to you.  You are
picky and find spaces and artifacts of redlining, which you fix and don't
even bother to redline. I'd call that version 1a, not even 1.1 much less 2.0
In the final PDF 1.0 with the fixes, I would not bother to reflect those
draftsman version control conventions.

How do other handle that? At some point this gets impossible academic and
must be relegated to the rule of common sense and good judgment.

On a side note. I'm going nuts with a large proposal team. Any suggestions
(other than an Exchange server) for tools or really useful website for
document collaboration with redlines?

Jim Keane
OdrXML


   /s/James I. Keane


   JKeane.Law.Pro





‘<Litigation Systems Analysis>’


    http://www.jkeane.com <http://www.jkeane.com/>


 20 Esworthy Terrace

 North Potomac MD 20878
 Phone: 301-948-4062
 Fax: 301-948-8924
 (N.B.: NEW FAX NUMBER)

Co-Author and Annual Update Editor of
  Litigation Support Systems, An Attorney Guide 2nd Ed.
<http://west.thomson.com/store/SearchResults.asp?Keyword=litigation+support+
systems&ProductType=Products&Submit.x=13&Submit.y=10>
(WestGroup, 1992, 800 pages, looseleaf, updated through 2002)


-----Original Message-----
From: Philpott, Robert [mailto:rphilpott@rsasecurity.com]
Sent: Thursday, May 29, 2003 5:51 PM
To: 'Eduardo Gutentag'; 'chairs'
Subject: RE: [chairs] File naming conventions


Eduardo - thanks for the update. A part of me wants to just say okay and
let's close on it.  But, ... see my (longwinded) comments below.

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: Eduardo Gutentag [mailto:eduardo.gutentag@sun.com]
> Sent: Thursday, May 29, 2003 4:09 PM
> To: chairs
> Subject: [chairs] File naming conventions
>
>
> overstrike. The modifications
> I propose in this revised HTML version are:
>
> 1) a sentence regarding adherence to the rules in the case of normative
> output

[Rob] In section 1, you added the text "Normative output must adhere to
these file naming rules" to the note on Bullet #2.  The "must" nature of the
sentence doesn't seem to really fit with all of the bullets here since they
are all "should's" describing general principles.  I actually would suggest
taking the entire "Note" off bullet #2 and either place it un-bulleted just
after the list or put it in Section 3.4 (Rules for TC Output). I'd also like
to suggest alternative text to yours such as "It is required that all
normative TC outputs adhere to these general principals and the specific
naming rules described in Section 3" (if moved to Section 3.4, appropriate
section reference changes are needed).

> 2) a deletion of tcid in the examples
[Rob] I can live with the deletion, although I would have leaned toward
including the tcid; it seems a bit more descriptive.  If I run across a file
sstc-philpott-foo.doc in my local oasis folder, I know it was a submission
to sstc. This might be helpful if the description part (foo) happens to
include the name of another TC (e.g. a document submitted to a TC that talks
about its relationship to another TC).

> 3) a sentence regarding adherence to the spirit of the recommendation
>
[Rob] Looks fine to me.

There is one TC output that I don't feel the naming convention is clear
about and I'd like us to include something for it in the document.  Namely,
how do we name an errata document? It sounds simple enough, but I began to
dwell on it a bit as we began preparing the SAML 1.1 errata doc.  The reason
is that a) an errata document is not a formal CS or standard document
(right?) since it's created after a CS or standard vote, b) your CS and
standard specs are supposed to include a reference to your errata doc (or so
says the document template), and c) the errata doc file name would probably
refer to the CS or standard to which it applies.  That complicates the name
a bit, I think.

As an example, what would draft 2 of an errata document for the SAML V1.1
Committee Specification be named?

I think I would use the
"tcid-description-version-draft-revision[-extdesc].ext" format. So should we
use "sstc-saml-cs-errata-1.1-draft-02.doc" ("description"="saml-cs-errata")?
Between this and a bunch of other options I thought about, I think this one
made the most sense.  It's just that the "-cs" is part of the description
and isn't really referring to the other name format
"tcid-description-version-cs[-revision][-extdesc].ext"

In either case, I don't think this is a significant change to the naming
recommendation - I think we can just add another example line in Section
3.4. I'd just like some advice on how to name an errata document.


You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/chairs/members/leave_workgroup.
php