Indeed Doug, I think you are reading too much into this. :-) Frankly, I’ve never heard that a v2 mandated a “breaking change.” Again, we can change the version any time.
Version-less documents will be potentially confusing and even harmful, especially given the open nature of OASIS. I would be against that possibility, I’m afraid, but am certainly open to other possibilities, if the TC really cares.
That said; allow me to point out, in a friendly fashion, that you said “waited until the TC made changes
to our document” and now you appear to want to talk about it next week before any changes to the document are made. Frankly, I would think a more informed discussion closer to when we
have our first CSD, in the spirit of your original suggestion, makes more sense. Can you wait until then?
That said; if you feel the matter is simply too red-hot for a slightly later, more informed discussion, of course I will respect that your feelings and place the discussion
on the agenda. As long as we don’t have version-less documents, which are potentially risky and confusing to the general public, I don’t care what version we assign now. We could even use the v.next term in the title, if the TC prefers. That might actually
be the best course of action. What do you think? Would anybody object to it?
Thanks,
Paul
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Friday, April 05, 2013 5:20 PM
To: Lipton, Paul C
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] Starter Document for Topology and Orchestration Specification for Cloud Applications Version 2.0
I would actually prefer a version-less title because of the implications that including 'v2' in there will mean to people - mainly a set of breaking changes. Or maybe I'm reading too much into
presence of these docs all together and all we really care about is the new template and the editors will make the conversion using the existing v1 content. In which case its definitely not a v2 - it more like a v1.errata since there are no normative changes
- just an oasis template change. Was this discussed during the call? Sorry if I missed it.
Here's a possible scenario... we find that the current spec is basically ok as is - there might be some minor tweaks that can be dealt with in an errata but overall its fine. However, as you said,
we need to define some concrete node types. I'm not convinced that they would go into the current spec. They might go into a new document to highlight the separation of the tosca abstract notions from the concrete node types. That doesn't require a tosca
v2. Or, perhaps we do stick it into the current doc but because the existing features are untouched, its all non-backwards-breaking-changes, this again doesn't mean its a v2 it could be a v1.1.
The key thing to me is that v2 implies a set of breaking changes and we're not there yet and I don't feel comfortable assuming we'll have any. Rather than making a premature decision I'd prefer
to see how things play out. I think its far more important that we focus on interop testing of v1 and see where that leads us.
Let's discuss this on the next call.
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" ---04/05/2013 05:01:58 PM---Hi Doug, OASIS Staff requested that we start with fresh templates for the spec and the primer, in pa
From:
"Lipton, Paul C" <Paul.Lipton@ca.com>
To:
Doug Davis/Raleigh/IBM@IBMUS, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>,
Date:
04/05/2013 05:01 PM
Subject:
RE: [tosca] Starter Document for Topology and Orchestration Specification for Cloud Applications Version 2.0
Sent by:
<tosca@lists.oasis-open.org>
Hi Doug,
OASIS Staff requested that we start with fresh templates for the spec and the primer, in part to make sure the format aligns with the latest OASIS format. We are required to provide a title and
rather than opt for a version-less title or a confusing one, I selected a title that was consistent with a version designation that the entire TC has been using freely. This is not necessarily a permanent title by any means.
I suggest we live with v2.0 as a proper, but “working title” for these working drafts, which have no real standing anyway, prior to the first Committee Spec Draft. As you say, we can have that
discussion prior to CSD at which point we’ll certainly know if we need to change the version.
That said; co-chair hat off now, I think our frequent, albeit perhaps subconscious use of the term v2 was telling. Just look at the lack of base classes in the current spec that we intend to
specify, and the already present large volume of documents that have been generated by the Interop SC. It seems extremely hard to believe that all of that constitutes an errata or v1.1, if we are to be honest with ourselves.
I hope that the situation and the lack of “title lock in” makes some sense to you and eases your concern.
Thanks,
Paul
From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Doug Davis
Sent: Friday, April 05, 2013 4:31 PM
To: tosca@lists.oasis-open.org
Subject: Re: [tosca] Starter Document for Topology and Orchestration Specification for Cloud Applications Version 2.0
tosca-chairs,
during the call on Thursday we talked a lot of v2 activities and perhaps I should have given the terminology more consideration (or I apologize if this was discussed during the call and I missed it) but I was interpreting the talks to really be about v.next
- meaning "whatever we do next". Whether that turns out to be a full v2, a v1.x or just an errata is yet to be seen. So, I was a bit surprised to see these "starter" documents get created with the assumption that we're immediately going to work on a v2.
I would prefer that we didn't make this assumption and waited until the TC made changes to our documents and _then_ we decided how best to release those - ie. as an errata, v1.x or v2. I think its too soon to jump to the v2 conclusion.
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.
Paul
Knight ---04/05/2013 03:32:45 PM---Per the TC's submission request [1], please find the attached starter document for:
From: Paul Knight <paul.knight@oasis-open.org>
To: tosca@lists.oasis-open.org,
Date: 04/05/2013 03:32 PM
Subject: [tosca] Starter Document for Topology and Orchestration Specification for Cloud Applications Version 2.0
Sent by: <tosca@lists.oasis-open.org>
Per the TC's submission request [1], please find the attached starter document for:
Topology and Orchestration Specification for Cloud Applications Version 2.0
WP-abbrev: TOSCA
We expect this Work Product to be published at:
http://docs.oasis-open.org/tosca/TOSCA/v2.0/csd01/TOSCA-v2.0-csd01.doc
Please let me know if anything here fails to meet your expectations.
Further revisions to this Work Product must be maintained in Working Drafts, following procedures detailed in the OASIS TC Administration How-to Guide [2].
Working Drafts should be made available by uploading the document(s) to the TC's Kavi document repository, or (provisionally/temporarily) to the TC's Subversion (SVN) repository, if SVN has been activated for your TC [3]. TCs are encouraged to use ZIP packaging
when the WD releases contain multiple files (and directories).
For each WD revision, you will need to:
1) increment the Working Draft revision (number) from 01 to 02, 03, 04 etc., as successive Working Drafts are produced; the revision number needs to be updated at the top of the document in the stage identifier (Working Draft ##) and in the document identifier
within the page footer.
2) supply the relevant publication/release/upload date for each successive Working Draft instance, using the prescribed date format: DD Month YYYY; the date needs to be updated at the top of the document (just below the stage identifier, Working Draft ##)
and in the page footer.
3) provide suitable text for a document Abstract, updating this summary with successive revisions to provide an accurate description of the subject matter, goals, scope, etc.
4) keep the Acknowledgments (Appendix A) and Revision History (Appendix C) up-to-date with each WD revision.
5) consult the OASIS Naming Directives document when creating new artifacts that may be part of the Work Product (e.g., image files, XML schemas), observing the rules for name characters in files and proposed directories, and for proposed URIs/namespaces [4].
When the TC votes [5] to approve a Working Draft as a Committee Draft (CSD or CND), the Chair or other designated person must submit a "Committee Specification Draft Creation and Upload Request" accessible on the TC Administration Requests Page [6].
Upon receipt of this form, the TC Administrator will QC and process the Work Product for official publication in the OASIS Library (http://docs.oasis-open.org/) as a Committee Draft, including addition of the requisite
cover page metadata and other boilerplate information.
=========== References:
[1] https://tools.oasis-open.org/issues/browse/TCADMIN-1237
[2] Developing Committee Specifications and Notes
https://www.oasis-open.org/resources/tcadmin/developing-committee-specifications-and-notes
Starting a Working Draft
https://www.oasis-open.org/resources/tcadmin/starting-a-working-draft
[3] SVN Version control, via Tools
https://tools.oasis-open.org/
[4] OASIS Naming Directives
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html
[5] Approval of a WD as a CD (CSD or CND)
https://www.oasis-open.org/resources/tcadmin/approving-a-committee-specification-or-note-draft
https://www.oasis-open.org/policies-guidelines/tc-process#committeeDraft
[6] TC Administration Requests Page, see Committee Specification Draft Creation / Upload Request
https://www.oasis-open.org/resources/tc-admin-requests
Best wishes,
Paul
--
Paul Knight - Tel: +1 781-861-1013
OASIS - Advancing open standards for the information society
Document Process Analyst
[attachment "TOSCA-v2.0-wd01.doc" deleted by Doug Davis/Raleigh/IBM]
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php