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

[Hiro Kishimoto]

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&group_
> 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).
>