[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [chairs] Draft Jan 2009 TC Process changes summary
OASIS, and SSOs of its ilk, tend to focus on interoperability specifications. In that light, concepts such as conformance, specification, normative etc have particular meaning. As it happens, in almost every SSO that I have participated in, my work has almost never been around an interoperability specification but an architectural specification. Conformance and architecture are uneasy bedfellows; for the foreseeable future, it seems unlikely that we will ever develop automation in verifying that an actual architecture of an actual product conforms to (or does not conform to) an architectural specification. On Jan 23, 2010, at 2:36 PM, Ken Laskey wrote: > Would it be useful to discuss this in terms of normative vs. informative? > > Things that are normative become so by being labeled as such in "specifications" that are identified as "standards". In most cases, the entire standard's specification is assumed normative except for those portions specifically labeled as not. > > Things we look to publishing as Notes are informative, i.e. these will provide guidance for how to effectively use the standards but are not required usage as far as OASIS is concerned. This does not stop someone else from declaring these required for their domain of use, but that is outside OASIS control pr responsibility. > > IPR issues apply most directly to things that are normative because there is no way around the normative specifications. Things that are informative may be very detailed, but these are not required. > > Note, you could have conformance statements for either normative or informative work. These tell you whether you conform, nothing more and nothing less. > > Ken > > On Jan 23, 2010, at 3:42 PM, 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 >> >> -- >> >> Robin Cover >> OASIS, Director of Information Services >> Editor, Cover Pages and XML Daily Newslink >> Email: robin@oasis-open.org >> Staff bio: http://www.oasis-open.org/who/staff.php#cover >> Cover Pages: http://xml.coverpages.org/ >> Newsletter: http://xml.coverpages.org/newsletterArchive.html >> Tel: +1 972-296-1783 >> >> ----------- >> >> On Sat, 23 Jan 2010, Jon Bosak wrote: >> >>> Jim Hughes (LCA) wrote: >>>> +1 to Jeff's comments. And we should be very precise with >>>> terminology in these discussions... >>> >>> Then let's start with the word "specification." This is not a >>> word that OASIS invented; believe it or not, it has a prior use in >>> English. The ordinary English meaning of the word is: "a specific, >>> explicit, or detailed mention, enumeration, or statement of >>> something." >>> >>> As I said earlier in this thread, the word "specification" >>> >>> applies to a lot of things that we're going to be calling >>> Notes. For example, the UBL Guidelines for Customization >>> constitute "a specific, explicit, detailed mention, >>> enumeration, and statement" of our guidelines for >>> customization. The document is a specification of our >>> guidelines. >>> >>> I would go so far as to say that *most* things that TCs are going >>> to want to publish as "Committee Notes" are, in fact, >>> specifications according to the ordinary English meaning of the >>> word -- the meaning that speakers of English who are not OASIS >>> members intend. >>> >>> This wouldn't be terribly important if we didn't make statements >>> like this: >>> >>>> I'm not questioning the presence of Conformance Clauses, if you >>>> have a specification - the point is that when we start talking >>>> about them in the context of *non-specifications* it becomes >>>> much murkier. >>> >>> This implicitly argues that because Notes are not Specifications >>> in the special OASIS-only use of the word then they are not >>> specifications in any sense of the word. This is not true, and it >>> begs the question of what constitutes a specification. Try >>> substituting the term "Non-standards-track Specifications" for >>> "Notes" and see what happens to that argument. >>> >>> I'm not saying anything here about whether conformance clauses >>> should be allowed in Notes. I'm saying that equivocation and >>> arguing in circles is not a good way to sort this out. >>> There may be a good reason to exclude conformance clauses from >>> Notes, but it's not just because they're called Notes. >>> >>> Jon >>> > > ----------------------------------------------------------------------------- > Ken Laskey > MITRE Corporation, M/S H305 phone: 703-983-7934 > 7515 Colshire Drive fax: 703-983-1379 > McLean VA 22102-7508 > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]