OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj message

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


Subject: Re: [tm-pubsubj] Vote on Requirements document


At 10:38 18/02/02 +0100, Bernard Vatant wrote:
>The "Requirements for Documentation of Published Subjects" ...
>http://www.oasis-open.org/committees/tm-pubsubj/docs/requirements/part1.htm
>
>... has not yet been formally approved by the TC.
>
>This is the official call for vote on document approval.

I'm wondering if we shouldn't rename *all* of these documents...

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.

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.

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.

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.

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.

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!)

Steve

--
Steve Pepper, Chief Executive Officer <pepper@ontopia.net>
Convenor, ISO/IEC JTC1/SC34/WG3  Editor, XTM (XML Topic Maps)
Ontopia AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway.
http://www.ontopia.net/ phone: +47-23233080 GSM: +47-90827246



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


Powered by eList eXpress LLC