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

[Milojicic, Dejan S]

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