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

[Milojicic, Dejan S]

Hi Hiro,

Thanks for your feedback. Maybe we should talk by phone to more
effectively resolve the issue. I am in the office right now (650
236-2906), if you provide your phone number, I'd be glad to call you.

I think that that there is a benefit in promoting both as standards and
I do not see that they impact each other if both are standards. One is
more appropriate as human-oriented, the other one as machine oriented.
We are very close to completing the XML-based CDL, it is the next one in
queue. Having SF-based as a standard will by no mean influence
wider-spread use of XML-based language as a standard. Is this your main
concern? Let's talk some more so that we can close on it.

Thanks 

Dejan. 

> -----Original Message-----
> From: Hiro Kishimoto [mailto:hiro.kishimoto at jp.fujitsu.com] 
> Sent: Saturday, December 11, 2004 11:38 AM
> To: Milojicic, Dejan S; cddlm-wg at ggf.org
> Cc: 'Gregory Newby'
> Subject: RE: [cddlm] SF-based language spec, dilemma whether 
> to go with a recommendations or common practice document track
> 
> 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&grou
> > p_
> > 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).
> > 
> 
> 
>