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

[Robin Cover <robin@oasis-open.org>]

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