RE: [chairs] File naming conventions

["Philpott, Robert" <rphilpott@rsasecurity.com>]

Hi Eduardo - thanks for the response.  As I read Section 2(b), the only
mention of errata is in the paragraph discussing the period of time from
when a CS is officially submitted to OASIS by the 15th of the month for
consideration as a standard and the end of the voting period. 

I do not interpret that to mean that a TC cannot produce an errata document
period. Do you know for sure that was what was intended?  Perhaps Karl could
clarify.  I just didn't read it that way.

I can understand why an errata document should not be considered as part of
a submission that's in the process of being voted upon.  Clearly, everyone
has to vote on what was submitted; not on the submission and other docs as
amended by postings after some folks may have voted.
  
But it seems strange to me that an errata document would never be permitted.
BTW - if that's true, then someone needs to fix the OASIS spec sample
working draft (wd-spectools-word-sample-04), which states on lines 35-36:

[If a Committee Specification or OASIS Standard:] The errata page for this
specification is at http://www.oasis-open.org/committees/xxx/yyy.

So, a CS or OASIS Standard that follows the template would clearly need an
errata page.

I guess I don't see a reason that an errata document wouldn't be allowed (or
perhaps even desired) at other times than the submission/voting period.  For
example, a TC may have a V1.0 standard adopted, begin work on V2.0, and then
discover errata in the previous version that it wants to document for users
of the V1.0 standard so they don't interpret/implement something in the
wrong way.  

Clearly, an errata page should NOT describe any normative changes, but I
don't see how providing a document that describes editorial, non-normative
edits or clarifying text could be harmful. Of course, such a document isn't
an official part of the TC or standard, but it seems useful nonetheless. 

I think that there is also precedence with several TC's that have used an
errata document as a way to document the TC resolution of all appropriate
feedback on a spec during it's 30-day public review period (or other
internal TC reviews).  According to the TC process, following the public
review period, the TC can make the necessary changes and then re-affirm the
spec as a CS prior to submission for voting.  In this case, the errata
document is then simply a recording of errata in the public review version
of the spec and not the final spec.  My question was simply how such a
document needs to be "named" according to the rules outlined in the
conventions.

Thanks,

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: Friday, May 30, 2003 1:00 PM
> To: jkeane
> Cc: Philpott, Robert; 'chairs'
> Subject: Re: [chairs] File naming conventions
> 
> Please let me remind you all that Errata and/or Corrigenda are not
> permitted
> by the TC Process (see Section 2(b)). The assumption behind this is that
> in anything that is not final, all the TC has to do is correct the draft
> and
> issue it as a new version; that if it is a the stage of a TC Spec and
> errors
> are found, it should be withdrawn, corrected and reinstated as a TC Spec.
> And of course that if it is a Standard, it should have gone through so
> many inspection before reaching that level that there is indeed no need
> for corrections ;)
> 
> 
> jkeane wrote:
> > 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+suppor
> t+
> > 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
> >
> >
> 
> --
> Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
> Web Technologies and Standards |         Phone:  +1 510 550 4616 x31442
> Sun Microsystems Inc.          |         1800 Harrison St. Oakland, CA
> 94612
> W3C AC Rep / OASIS TAB Chair
> 
> 
> You may leave a Technical Committee at any time by visiting
> http://www.oasis-
> open.org/apps/org/workgroup/chairs/members/leave_workgroup.php