Not clear what you mean by “take the normative things out”. The details are needed for interoperability. If we want to dance around the fact that they are needed by saying “you might want to handle parameters this way, if you choose” we could pretend that it is non-normative. But if we actually leave the details out, the document is worthless.
I support the plan to keep the guide as a WD until v.next as long as that means (1) it’s covered by OASIS IPR and (2) there is a public URL pointing to the document to allow anonymous access.
Best,
--Richard
From: tosca-interop@lists.oasis-open.org [mailto:tosca-interop@lists.oasis-open.org] On Behalf Of Lipton, Paul C
Sent: Monday, January 14, 2013 11:31 AM
To: Doug Davis
Cc: tosca-interop@lists.oasis-open.org; Simon D Moser (SMOSER@de.ibm.com); Matt Rutkowski; Probst, Richard
Subject: RE: [tosca-interop] Re: Interop Guide - What is the Appropriate Track For Now?
Doug,
I’m merging in Thomas’s question and my response below, as the thread accidently got split.
We are on the same page in just about every way. I’m fine with normative things going into the spec and agree that is the ONLY place for normative content. It’s simple. If normative things belong in the spec and only the spec; either v1, v1.errata (limited to a narrow set of corrections), or v.next (v2), then don’t produce a Committee Note that contains normative things.
The current Interop Guide appears to have normative things and is not the TOSCA spec. As Doug says, that’s bad. So, our choices are simple:
1. Take the normative things (all of them) out of the Interop Guide (might reduce usefulness, but I have no objection)
2. Keep the Interop Guide at the WD level until v.next starts. Do not position the current WD or advance it as a Non-Standards Track work product (CND) in any fashion. When v.next begins, put the normative stuff in the spec and advance the v.next spec, as we normally do. Note:
a. There are no functional problems with this. Implementers inside or outside the TC can access the current document by using the public URL provided by Kavi until v.next begins.
b. Because normative stuff with standing belongs in the spec (as Doug said) and a CN, which is essentially intended for marketing material and high-level whitepapers, is the wrong track, we take care to keep our normative stuff where it belongs, in the spec (as per Doug).
c. A non-normative Interop/Best Practices guide becomes a separate consideration, at that point.
Thanks,
Paul
From: tosca-interop@lists.oasis-open.org [mailto:tosca-interop@lists.oasis-open.org] On Behalf Of Doug Davis
Sent: Monday, January 14, 2013 2:04 PM
To: Lipton, Paul C
Cc: tosca-interop@lists.oasis-open.org; Simon D Moser (SMOSER@de.ibm.com); Matt Rutkowski; Probst, Richard (richard.probst@sap.com)
Subject: [tosca-interop] Re: Interop Guide - What is the Appropriate Track For Now?
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?
-----Original Message-----
From: tosca-interop@lists.oasis-open.org [mailto:tosca-interop@lists.oasis-open.org] On Behalf Of Lipton, Paul C
Sent: Monday, January 14, 2013 2:06 PM
To: Thomas Spatzier
Cc: dug@us.ibm.com; Matt Rutkowski (mrutkows@us.ibm.com); Probst, Richard (richard.probst@sap.com); Simon D Moser; tosca-interop@lists.oasis-open.org
Subject: RE: [tosca-interop] Interop Guide - What is the Appropriate Track For Now?
Hi Thomas,
What we do with the Interop Guide should not affect our timeline for v1 Spec at all. That should continue to go forward towards OASIS Standard at all due speed. Each work product (doc) has its own path, votes, etc.
Hope I'm understanding the question correctly.
Thanks,
Paul
-----Original Message-----
From: Thomas Spatzier [mailto:thomas.spatzier@de.ibm.com]
Sent: Monday, January 14, 2013 1:25 PM
To: Lipton, Paul C
Cc: dug@us.ibm.com; Matt Rutkowski (mrutkows@us.ibm.com); Probst, Richard (richard.probst@sap.com); Simon D Moser; tosca-interop@lists.oasis-open.org
Subject: Re: [tosca-interop] Interop Guide - What is the Appropriate Track For Now?
Hi Paul,
so does that mean that we can still keep the timeline for the "core" TOSCA spec (i.e. don't have to re-do public review and so on) and just start a draft of another sibling "spec". If that is possible, then I guess it sounds like a good solution. Because I tend to agree that the document is more than just hints and tipps on implementation ...
Regards,
Thomas
---------------------------------------------------------------------
IBM Deutschland Research & Development GmbH Tivoli Service Automation Manager Development, D2705 Schoenaicher Str. 220, D-71032 Boeblingen, Germany
Phone: +49-7031-16-1219
Email: thomas.spatzier@de.ibm.com
IBM Deutschland Research & Development GmbH / Vorsitzende des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
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