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


Jeff,

Jeff Mischkinsky wrote:
>
> 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?
Let's see:

1) CN's cannot to to OASIS-wide vote

2) Cannot be submitted to outside bodies

3) Not intended for normative reference (I am sure someone will ask for 
that to be policed inside OASIS)

Does that sound like CN's are somehow "less than" standards? (I won't 
continue the confusion of specification with standard.)

Hope you are having a great day!

Patrick


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

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



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