Hi, I just want to forward to the group the following very helpful response from Stephen Pickles, regarding a question I asked about the completion criteria for CDDLM. Regards, Peter -----Original Message----- From: Stephen M Pickles [mailto:Stephen.Pickles@manchester.ac.uk] Sent: 25 September 2006 19:10 To: Toft, Peter; Hiro Kishimoto Subject: RE: CDDLM-WG completion criteria? Hi Peter, and welcome. A group is finished once it has completed its charter. (You should check that the charter still matches the group's plans). For CDDLM, I imagine this means bringing all of the specifications you list through to "Recommendation" status - that's when they become OGF standards. You're close to having "Proposed Recommendations" for these specs. A proposed recommendation is one that's been through public comment and is published in the GFD document series as a proposed recommendation. That is, it's listed on http://www.ogf.org/gf/docs/?final has a GFD number, and has "REC" in the document type column. (The document process is described in GFD.1, which you should read, if you haven't done so already.) Plenty of OGF specs are proposed recommendations. None have attained full recommendation status. I hope that CDDLM will be one of the first. To go the final mile towards getting the highest status, you need to write an experimental (EXP) document (possibly more than one, if it makes sense to treat each spec separately) which essentially prove the case that there are multiple, independent interoperable implementations of the spec(s). This EXP document becomes input to a formal review (which might involve external reviewers), on the basis of which the decision to award (or not award) recommendation status is made. What "interoperable" means to some extent has to be localised to the spec. I know from Steve Loughran that CDDLM has done a lot of work on testing interoperability, so probably you've done most of the work and just need to write it up. When you do so, imagine yourself in the position of an external reviewer. (Is the spec sound? Is it clear enough that a developer can write an implementation that "interoperates" with others from material in the spec alone? Do I believe that group has done "due diligence" in this area? Do I believe that the interoperability testing as described tests what should and can reasonably be tested? Do I have any doubts about the independence of the implementations?) What some groups are doing is writing their interop plans down in an INFO document before going about their interop work. I think this is a good practice (and a good way of getting more eyes on the approach to testing), but you're probably already beyond this for CDDLM. Most importantly, you should keep in contact with your Area Director. That's Hiro. Hope this helps, Stephen

-----Original Message----- From: Toft, Peter [mailto:peter.toft@hp.com] Sent: 25 September 2006 17:13 To: Hiro Kishimoto; Stephen M Pickles Subject: CDDLM-WG completion criteria?

Dear Hiro, Stephen:

As you probably know, I recently took over co-ordination of the CDDLM-WG from my HP colleague Dejan Milojicic. Although I was involved in the inception of the group, I have been somewhat out of the loop for the last couple of years so I have some catching up to do.

What I want to check with you is what it means for CDDLM to be 'done' -- at least for the first pass at the standards. What we are currently working towards is an agreed specification set:

- CDL Language - Deployment API - Component Model

All of these are complete except for a resubmission of the revised CDL.

To accompany each of these, we are running interoperability tests against three separate implementations of each of the specifications. The results of these tests will be captured in formal documents, one for each specification, which will be submitted to the OGF editorial process.

So, given acceptable versions of each of these documents and the open source availability of some number of reference implementations, what else is needed to bring CDDLM-WG to a graceful conclusion?

Thanks and best regards, Peter