Re: [tm-pubsubj] Vote on Requirements document

[Bernard Vatant <bernard.vatant@mondeca.com>]

Steve

> In my posting on Jan 31 I suggested renaming the document now entitled
> "Recommendations for Documentation of Published Subjects" as "Requirements
> and Recommendations for the Documentation of Published Subjects" -- because
> we want to be able to both require and recommend in the same document.
> Bernard concurred, but the old name is still in use on the web site.

Mea culpa. Updating the TC web site have somehow been stuck in *next* position in my
*urgent* file since three weeks :(

> That document is the "real" deliverable (from the point of view of the
> outside world) -- at least as far as *documentation* of published subjects
> is concerned. The document we are now approving, with the misleadingly
> similar title, is more like a terms of reference for the work of the TC itself.

Agreed. The term "requirements" has been there from the beginning in the charter, and it
is confusing indeed.

> I propose therefore the following naming structure, using titles and subtitles:
>
> Final deliverables:
> ------------------
>
> (1) Documentation of Published Subjects:
>      Requirements and Recommendations.
>
> (2) Management of Published Subjects:
>      Requirements and Recommendations.
>
> (3) Usage of Published Subjects:
>      Requirements and Recommendations.

That looks very good to me.

> TC process documents:
> --------------------
>
> (A) Documentation of Published Subjects:
>      Committee Requirements.
>
> (B) Management of Published Subjects:
>      Committee Requirements.
>
> (C) Usage of Published Subjects:
>      Committee Requirements.
>
> Maybe someone can come up with a better subtitle for the "process
> documents", but you get the general idea.

Yes. Not completely happy with the wording. What about adding "process" in each document
title, like

(A) Documentation of Published Subjects:
     Committee Process Requirements.

> We are now voting to approve (A), which will be our guide as we develop
> (1). My understanding is that we can tweak (A) along the way as our
> understanding of the problem space evolves. Provided that is the case, I
> approve (A) as is, subject to the naming issue being cleared up.

That looks like a "yes, but" ... :))

I also think we are not tied up by (A), that is only internal guidelines and reference
roadmap, and that it will never have any kind of external recommendation status as
deliverables will have. I thought we were all tuned on that, but maybe we needed that
precision. Thanks for providing it.

> Re. Scott's proposal to change the name of "published subject documentation
> set" to "published subject documentation":
>
> I think it makes more sense to wait with this decision. To my mind PSDS is
> still just a working term, and I don't think we are quite ready to finalise
> terminology yet. For example, when doing the strawman PSI set a couple of
> weeks ago, I experienced an irresistible urge to introduce the term (guess
> what?) "PSI set", and I didn't need PSDS at all.
>
> I think we all need to work with concrete examples before we can nail this
> down once and for all. (Take that as a challenge!)

Agreed. See my previous answer to Scott.

Bernard