Option 2 also does NOT lead to conflicting normative standards documents because the Interop Guide (don’t even call it a WD) has no standing. You can upload all the normative
stuff you want into Kavi (and we have done so in the past). In terms of OASIS standards, it doesn’t mean anything. Use it to implement something related to TOSCA, if it makes you happy, but make no claims relative to the Interop Guide, of course. Make your
claims regarding the spec, which is normative.
As per your question below, Doug, your point is well-taken. As with any other bug/issue/improvement in the spec, the Interop SC will need to open JIRA issues for any changes
to the spec that it wishes to recommend. The process would be no different than what we did for Spec v1.
I would recommend the Interop SC first open JIRA bug issues that do not change the function or scope of the spec as soon as they can. They could probably be considered for
a non-material change to Spec v1, or later in a v1 errata, or at least put into the first v.next CSD that way.
Enhancements and new material such as BASH script stuff should be put in a JIRA issue when the Interop SC a little later, but before the “pipeline” for v.next is empty again,
no doubt.
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 3:28 PM
To: tosca-interop@lists.oasis-open.org
Subject: RE: [tosca-interop] Re: Interop Guide - What is the Appropriate Track For Now?
Option 1 is the only one presented that doesn't lead us to conflicting normative documents. If the spec is missing something, which is implied when people say the guide currently contains stuff
needed in order to achieve interop, then open a new bug report and let's fix it. This is no different than if I noticed something missing from the spec today by just reading it and wanted to get it fixed - the fact that it was found as part of the development
of the interop guide should be irrelevant to how it gets resolved in the spec.
Question: for each normative statement in the guide, is there a bug report for it? If not, why not? If so, let's get it resolved and propose an v.errata or v1.next be published at the same time
as the interop guide. I don't see why this would impact interop or usefulness of the interop guide.
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 02:31:21 PM---Doug, I'm merging in Thomas's question and my response below, as the thread accidently got split.
From:
"Lipton, Paul C" <Paul.Lipton@ca.com>
To:
Doug Davis/Raleigh/IBM@IBMUS,
Cc:
"tosca-interop@lists.oasis-open.org" <tosca-interop@lists.oasis-open.org>, "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>
Date:
01/14/2013 02:31 PM
Subject:
RE: [tosca-interop] Re: Interop Guide - What is the Appropriate Track For Now?
Sent by:
<tosca-interop@lists.oasis-open.org>
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