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


Help: OASIS Mailing Lists Help | MarkMail Help

chairs message

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

Subject: Re: [chairs] Draft Jan 2009 TC Process changes summary


I think your point about not adopting a strained use of the word 
"specification" that is inconsistent with its usage elsewhere is well 
taken. I want OASIS to distinguish itself but by the quality of the work 
it produces, not by the oddity of its vocabulary.

I suppose I should thank Jim Hughes for encouraging close attention to 
the language in this debate as that caused me to return to the top of 
the thread and Jeff's initial post.

One of the things Jeff highlights:

> A non-standards track work product stops at the Committee Note level.  
> Therefore it may NOT be put up for an OASIS-wide vote, unlike a  
> standards track work product, nor submitted to an outside (de jure)  
> body.
> Committee Notes will have different templates, cover pages, etc. to  
> distinguish them from specifications/standards. They are not intended  
> to be normatively referenced by other standards (either inside or  
> outside of OASIS), though of course there is no way to actually stop  
> someone from doing so (hence the IPR safeguards and rigorous review/ 
> approval process).

There is a continuum of documents that don't become standards, ranging 
from presentations to requirements and best practices and other 
documents as well. What is troubling about the current proposal is that 
it lumps all of those documents into one single, second-class category.

Or at least it appears to, although Jeff notes at the end of saying they 
can't be normatively references they have:
> (hence the IPR safeguards and rigorous review/ 
> approval process).
If they have the same IPR safeguards and rigorous review/approval 
process, why are they second-class citizens?

Hope you are having a great weekend!


Robin Cover wrote:
> [Jon Bosak]
>> As I said earlier in this thread, the word "specification"
>> applies to a lot of things that we're going to be calling
>> Notes.
> +1 in the extreme
> Several times I have tried to make the point that the
> current program to restrict the word "specification" to
> Standards Track work products is (IMO) a very misguided
> agenda. It will pointlessly confuse people and I think
> it will make OASIS look silly.
> I have noted that in all SSOs/SDOs I know about from
> first-hand experience and in those I've researched, the
> word "specification" is the generic, garden-variety
> term that is used in reference to any kind of technical
> work that describes, recommends, prescribes, or uses
> language formalisms everyone recognizes as appropriate
> for a "specification."
> A "specification" is characterized by virtue of its
> form and content -- not by some decision of an SSO/SDO
> to advance the document through a certain process of
> standardization in a formal body.  "Specifications"
> are produced by engineering teams for private use
> in IT companies. Specifications (think of the history
> of PDF) are often entirely proprietary formulations
> that eventually become successful and are contributed
> to a standards body for standardization -- but they
> are "specifications" independent of any standardization
> process.
> I do understand the goals of ensuring that IPR protections
> are clearly communicated, that OASIS levels of approval
> are clear, and that documents produced within OASIS
> have clear status labels.  But I think the attempt to
> restrict the term "specification" to Standards Track
> documents flies in the face of common language usage,
> as practiced across many SSOs/SDOs that allow for
> various genres and classes of specifications without
> reserving the term "specification" for just Standards
> Track.
> According to my analysis, many kinds of documents produced
> legitimately within the scope of OASIS TC work are in
> fact "specifications", but the new language of the TC Process
> would not countenance use of that label because the
> were not ratified at Committee Specification or OASIS
> Standard level.
> Respectfully submitted,
>  - Robin Cover

Patrick Durusau
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

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