[cddlm] SF-based language spec, dilemma whether to go with a recommendations or common practice document track

[Milojicic, Dejan S]

Hi Greg,

Thanks for the follow email. I would suggest that we focus the
discussion on whether there is a need for a user-friendly (SF-based) in
addition to the machine-friendly (XML-based CDL) language for deployment
and configuration mgmt rather than whether there is a plan at the moment
for a new reference implementation or not. The fact that there is no
plan at the moment does not mean that there will not be another
reference implementation in the future. 

Thanks,

Dejan.

PS Your original email bounced from the CDDLM mailing list because you
are not a member, but I include it below.
-----Original Message-----
From: Gregory Newby [mailto:newby at arsc.edu] 
Sent: Monday, December 13, 2004 12:11 PM
To: Hiro Kishimoto
Cc: Milojicic, Dejan S; cddlm-wg at ggf.org
Subject: Re: [cddlm] SF-based language spec, dilemma whether to go with
a recommendations or common practice document track


I've suggested this be added to the next GFSG conference
call, to gather feedback.  I understand the reasoning
on both sides.

The one factor that might be critical is that the
2nd reference implementation is a requirement for
publication as a recommendation (at least, it seems
to be under GFD.1).  If there are no practical
plans for a 2nd reference implementation, that might
provide a solid practical reason for going with another category.

I hope we'll have more info/feedback from GFSG after
tomorrow's call (Tuesday), though it's possible the
discussion won't happen until next Tuesday.
  -- Greg


On Sun, Dec 12, 2004 at 04:38:17AM +0900, Hiro Kishimoto wrote:
> Hi Dejan, Greg,
> 
> I appreciate your efforts to choose most appropriate category for this

> document. I feel regret that "community practice" is not applicable 
> for the SF-based language spec.
> 
> Dejan: I understand your dilemma, but may I re-state my biggest 
> concern for this issue? I believe that interoperability of CDDLM 
> services among multiple implementations should achieved by XML-CDL 
> language.
> 
> >From the GGF11 session minutes;
> > Note that the SF CDL is intended to be more user-friendly /  
> >user-tractable, while the XML CDL is more standardised, is the 
> >interop  format (i.e. we can translate from various front ends into 
> >the XML  form), but is less user-friendly to use directly.
> 
> Expecting or encouraging the second implementation of SF-CDL
> is bad idea, IMHO. For wider adoption of the CDL, implementation of
> XML-CDL should be promoted. 
> 
> Thus, the CDDLM-WG should publish XML-CDL language spec as 
> recommendation and SF-CDL language spec NOT as recommendation. 
> Otherwise, you will mislead the community by sending confused message.
> 
> On the contrary, are there any issues if SF-CDL language spec becomes 
> informational document? I see no formality problems on informational 
> document because it is stable, open, and has clear IPR.
> 
> Thanks,
> ----
> Hiro Kishimoto
> 
> 
> > -----Original Message-----
> > From: owner-cddlm-wg at ggf.org [mailto:owner-cddlm-wg at ggf.org] On 
> > Behalf Of Milojicic, Dejan S
> > Sent: Thursday, December 09, 2004 5:29 AM
> > To: cddlm-wg at ggf.org
> > Cc: Hiro Kishimoto
> > Subject: [cddlm] SF-based language spec, dilemma whether to go with 
> > a recommendations or common practice document track
> > 
> > Hi,
> > 
> > I had an extensive discussion with Greg Newby yesterday morning on 
> > various topics, but most of the time we spent discussing the 
> > recommendation that Hiro brought up: "Why is SmartFrog-based 
> > language specification submitted as a recommendation track?" To be 
> > even more specific, Hiro recommended that it be resubmitted as a 
> > "Community Practice" because there will not be two reference 
> > implementations as a result of the standardization process. I 
> > checked with two other main drivers (Softricity and NEC) and neither

> > indeed planned to pursue a reference implementation of the 
> > SmartFrog-based language at the time. I also checked with technical 
> > area directors and their recommendation was not to go with community

> > practices because that track is applicable to something that is as 
> > commonly used as FTP and they have not considered SF to be that 
> > wide-spread. With all this information on my mind I approached Greg 
> > to discuss whether we should change submission to experimental or 
> > even informational track.
> > 
> > Our discussion was quite productive. I updated Greg that SmartFrog 
> > is in fact in active use by a number of universities, HP, and other 
> > parties; that it has been open-sourced; and that the submitted spec 
> > is the most formal specification of the SF language (goes well 
> > beyond the reference manual published for the language, system, and 
> > component model). Then we discussed the issue of the target type. At

> > the moment the document has reached the point of the recommendation 
> > track and formally we can take it any way we want. The reasons for 
> > sticking with the recommendation track are the following:
> > 
> > a) At the moment it is not clear that there will or will not be 
> > another reference implementation and one already exists. Two other 
> > partners claimed that they will not create one, but it is possible 
> > that other parties may create one. We would need to come up with 
> > another independently implemented SF-language parser that would 
> > create the same output as the existing one.
> > 
> > b) If the XML-based language interoperates with the SF-based 
> > language, that would be another proof point (this would require two 
> > other reference implementations of the XML-based language specs, 
> > though, but this is also open or the discussion).
> > 
> > c) If after the process, there are no other reference 
> > implementations, we can still downgrade the document. However, Greg 
> > and I estimated the value of proceeding the recommendations track at

> > the moment.
> > 
> > I welcome comments to this discussion by email or by phone (650 
> > 236-2906 office, 650 468-3929 cell).
> > 
> > Hiro, I appreciate your thoughtful suggestion. It was a good 
> > observation and it took us some time to truly understand all the 
> > implications. I hope that the final outcome works for you. If not, 
> > I'd be glad to continue discussion until we find a solution that 
> > will work for everyone. As you can see from the Greg's note below, 
> > we also agreed to provide some additional front-matter to the 
> > document. Finally, I will submit this email to Source Forge to 
> > capture this discussion. I recommend that any follow-ups also be 
> > submitted there.
> > 
> > Thanks,
> > 
> > Dejan.
> > 
> > Greg's GridForge input is available at 
> > https://forge.gridforum.org/tracker/?func=detail&atid=414&aid=827&gr
> > oup_
> > id=90 and also copied below:
> > 
> > Comment By: Greg Newby (2004-12-08 11:35:03) Per a telephone 
> > conversation with Dejan, I now agree this should be recommendation 
> > track.  The authors are essentially providing a CDDLM specification 
> > which, at the same time, is the most formal specification for 
> > SmartFrog. There is already one reference implementation, and we 
> > anticipate there will be more by the end of the GGF's recommendation

> > review timeline.
> > 
> > Some additional front matter will be added to provide further 
> > background on  SmartFrog, as well as the nature of existing 
> > reference implementations and the relationship to CDDLM (as an 
> > application area for SmartFrog).
> > 
> 
> 
> 
> 
> !DSPAM:41bb770f215203616814886!