[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [chairs] Draft Jan 2009 TC Process changes summary
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]