[occi-wg] OCCI Editor Getting Started Guide (docs/README.txt)

[Andre Merzky]

Hi Gary, 

Quoting [Gary Mazz] (Mar 28 2010):
> 
> Hi,
> I've been staying away from this discussion, but, I like Andre, am a
> little confused by the position and would like to see proven successes.
> My point of confusion was based in my own incorrect definition of the
> word "specification".  I was getting the word "specification" confused
> with word "standard".  Maybe clarification of the two words will help
> reset expectations, like it did for me.
> >From examining the dictionary definitions of the words, I didn't find
> anywhere in the definition of the word specification indicating it
> should be used as an authoritative reference. With this new
> understanding, I think it is acceptable and permissible to alter any
> specification as long as it does not violate any intellectual property
> ownership agreements, infringe on property rights, license agreements
> or copyright laws.

You are right, there are differences between specifications and
standards (aka standard specifications, aka standardized
specifications).  OGF is a standardization body, so more concerned
about standards (those OGF documents which become OGF
Recommendations).

While I agree that evolving specifications is a natural process, I
would argue that *standardized* specifications carry an implicit
promise that, if 2 implementation adhere to that standard, they are
interoperable.  That promise is broken if two different
specifications exist (same name, same version).

Basically, all OGF is asking for right now is, that instead of
forking, a new name or version number is applied to a specification,
so that a specific OGF recommendation can still carry that interop
promise.

Cheers, Andre.


> Interest in the stability of specifications is a legitimate concern,
> and a common risk for anyone using a 'specification' that's not a
> "standard". If this is concern for OCCI specifications, I would suggest
> moving the OCCI "specifications" and Getting Started Guide on a path
> toward "standardization" backed by an "authoritative" organization.
> Or did I miss the point of the 50 some odd emails :)
> -gary
> I took the liberty to go to dictionary.com and copied the six relevant
> definitions of the word "specification".
> 
> –noun
> 1.theact of specifying.
> 
> 2.Usually, specifications. a detailed description or assessment of requirements,
>  dimensions, materials, etc.,
> as of a proposed building, machine, bridge, etc.
> 
> 3.a particular item, aspect, calculation, etc., in such a description.
> 
> 4.something specified, as in a bill of particulars; a
> specified particular, item, or article.
> 
> 5.an act of making specific.
> 
> 6.the state of having a specific character.
> 
> Here is the definition of the word "standard":
> 
> –noun
> 
> 1.something
>  considered by an authority or by general consent as a basis of
> comparison; an approved model.
> 
> 3.a rule or principle that is used as a basis for
> judgment: They tried to establish standards
> for a new philosophical approach.
> 
> 5.standards,
>  those morals, ethics, habits, etc., established by authority,
> custom, or an individual as acceptable: He
> tried to live up to his father's standards.
> 
> 23.serving as a basis of weight, measure, value, comparison,
>  or judgment.
> 
> Here is the definition of the word "authority" used in one definition
> of "standard":
> 
> noun,plural-ties.
> 
> 1. the power to determine, adjudicate, or otherwise settle issues or disputes; j
> urisdiction; the
> right to control, command, or determine.
> 
> 2. a power or right delegated or given; authorization: Who has the authority to
> grant permission?
> 
> 3. a person or body of persons in whom authority is vested, as a governmental ag
> ency.
> 
> 4. Usually, authorities. persons having the legal power to make and enforce the
> law; government: They finally persuaded the authorities that they
> were not involved in espionage.
> 
> 5. an accepted source of information, advice, etc.
> 
> Here is the definition of the word anarchy:
> 
> –noun
> 
> 1. a state of society without government or law.
> 
> 2. political and social disorder due to the absence of governmental control: The
>  death of the king was followed by a year of anarchy.
> 
> 3. a theory that regards the absence of all direct or coercive government as a p
> olitical ideal and that proposes the
> cooperative and voluntary association of individuals and groups as the principal
>  mode of organized society.
> 
> 4. confusion; chaos;
> disorder: Intellectual and moral anarchy followed his loss of faith.
> 
> Andre Merzky wrote:
> 
> Hi Pieter,
> 
> its great to see some additional response, besides Sam :-)
> 
> 
> Quoting [Pieter Hintjens] (Mar 25 2010):
> 
> 
> On Thu, Mar 25, 2010 at 12:07 AM, Sam Johnston [1]<samj at samj.net>
> wrote:
> 
> 
> Mine too - if you can't reuse/remix the work then it's not free
> enough.
> 
> The ability to remix a standard seems an essential freedom: if a
> standard becomes too complex or encumbered by patents then this is
> the only way to save parts of it.
> 
> *sigh* my mail thread to that topic is counting well over 50 mails
> by now, and I still did not understand why people think that to be
> the case.  Would you or Sam please so kind and provide either an
> explicit example for a spec which has successfully been forked, or
> an explicit use case where that would be neccessary, and where the
> same cannot be achieved by referencing or profiling the old (complex
> or encumbered) standard?
> 
> What I (naively) think is that I can always create a specification
> like
> 
> "This specification defines an API API-B, which consists of the
> API defined in [orig], names API-A, with the call A removed, and
> the calls B added.  The call C changes its semantics to perform a
> nil operation.  Call D takes an additional parameter 'int size'
> which defaults to 1."
> 
> Voila, new API specified.  Same for interfaces, protocols, etc etc.
> Why do you need to fork a spec?  I don't get it, sorry...
> 
> Yes, the new API is called differently.  This is a *good* thing - I
> don't want to see two specs for API-A which define different syntax
> and semantics!  Are there use cases where one wants to break
> interoperability on purpose? *scratch*  I can't think of any.  At
> least the version number of the spec needs to change, IMHO.
> 
> 
> 
> That's why for Digistan we defined[1] the ability to fork a
> standard under a share-alike license as a necessary aspect.  We
> chose the GPLv3 mainly because it includes some safeguards against
> software patents, which CC does not.
> 
> I understand the concerns about patents.  But I think we agreed that
> this is out of scope for this specific discussion.  I am not sure if
> you are on the OCCI mailing list, so you may have not seen that part
> of our exchange.
> 
> We basically agreed I think, and this is also what you say I guess,
> that neither the OGF IPR nor CC-SA can provide any protection
> against 3rd party patent claims on technology required to implement
> a specification.  The best one can do is to obtain explicit patent
> waivers from those parties known to have claims on the relevant
> technology.  GPLv3 helps to some extent of course, but cannot
> provide protection against 3rd party patent claims either.
> 
> Thanks, Andre.
> 
> 
> -Pieter
> 
> 
> [1] [2]http://www.digistan.org/text:rationale#toc6
> 
> References
> 
> 1. mailto:samj at samj.net
> 2. http://www.digistan.org/text:rationale#toc6



-- 
Nothing is ever easy.