Re: Interop Guide - What is the Appropriate Track For Now?

[Doug Davis <dug@us.ibm.com>]

Paul,
  there are a couple of different topics here, IP vs normative text.  I won't touch the IP one because I don't really think that's relevant to what's the main point, which is whether a scenario doc is a 'spec' or more like a 'white paper'.  IMO, anything normative about TOSCA goes into the spec - period.  If its too late for the current release then it goes in the next one. If we can't wait for a full release then there's an errata process.  Creating a "sibling spec" for "things we didn't get into the real spec" is going to cause endless confusion since you will immediately have conflicts.  For example, if something isn't mandated in the spec, but it is mandated in the 'sibling spec' then that's a conflict since people are 100% compliant with the spec if they don't support those mandated pieces - after all, they followed _the_ spec.  When people say they support tosca v1.0 are they supporting "v1.0" or "v1.0+sibling spec" ?    Its going to be a mess.

This isn't rocket science and we've done this before (think WS* specs/processes). I don't see the need to think of this as something new or special - just follow the normal process.  Its really very simple.  As we do our interop testing, and coding, if people find issues we can open a new bug with the TC.  We'll discuss it and as part of the resolution we'll decide whether it should go into v2 or v1.next.  Then at some point someone will propose to release a new "spec" - whether that's v2, or v1.next or an errata is something they (and the tc) will decide at that point based on which issues are resolved, which need to be visible immediately, etc...

thanks
-Doug
________________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.

"Lipton, Paul C" ---01/14/2013 01:02:59 PM---Hi all, Matt suggested we take this Interop SC discussion offline due to lack  of time. Here's my co

From: "Lipton, Paul C" <Paul.Lipton@ca.com>
To: "tosca-interop@lists.oasis-open.org" <tosca-interop@lists.oasis-open.org>,
Cc: "Simon D Moser (SMOSER@de.ibm.com)" <SMOSER@de.ibm.com>, Matt Rutkowski/Austin/IBM@IBMUS, "Probst, Richard (richard.probst@sap.com)" <richard.probst@sap.com>, Doug Davis/Raleigh/IBM@IBMUS
Date: 01/14/2013 01:02 PM
Subject: Interop Guide - What is the Appropriate Track For Now?

---

Hi all,

Matt suggested we take this Interop SC discussion offline due to lack  of time. Here's my concern. 

I'm not a lawyer, but what I've always heard is that IP doesn't have to be an "advanced technology" for a vendor to have an essential claim. IP could be a specific API or a "page turn," as we've seen before in our industry. As I see it, I think the Interop Guide, as it currently stands, needs to be covered by OASIS patent provisions. It is not currently covered.

IMO, the Interop Doc has normative content, e.g., parameter order and statements like "The PrimaryScript element *must* also be specified in case the artifact template includes a single script only" (my emphasis). By placing this document, which might possibly contain IP, in the correct track as a Standards Track Work Product, we can release it just as quickly with some limited standing as a CSD just as easily as we could a CND, but with adequate patent provision protection for the TC members.

However, it is important to note that we are NOT locked into the standards track for the Interop Guide for v.next at the CSD stage. For v.next, I believe that we can easily refactor the spec and the interop guide as we see fit. If we want, we can move all the normative content from the Interop Guide to the Spec doc, and  return the Interop Guide to the Non-Standards Track as a true best practices document, with no harm done. 

Thanks,
Paul