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

[Jeff Mischkinsky <jeff.mischkinsky@oracle.com>]

On Jan 23, 2010, at 3:45 PM, Patrick Durusau wrote:

> Robin,
>
> 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.

Who said CNs are second class?
    -jeff
>
> 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!
>
> Patrick
>
> 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
> patrick@durusau.net
> 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)
>

--
Jeff Mischkinsky			          		jeff.mischkinsky@oracle.com
Director, Oracle Fusion Middleware 				+1(650)506-1975
	and Web Services Standards           			500 Oracle Parkway, M/S 2OP9
Oracle								Redwood Shores, CA 94065