Hi Paul, I really appreciate your efforts in maintaining this discussion, it brings a lot of value to the whole process! We have discussed your comments in the regular meeting this morning. You may hear from others, but here is my perspective. I think that we have taken a first, pragmatic step in standardizing deployment of apps and services. It may not be perfect, but it is definitely a step in the right direction. Also, we believe that it is the right level of completeness prior to having two reference implementations and then learning from them for the next version. Please see additional comments below.

-----Original Message----- From: owner-cddlm-wg@ggf.org [mailto:owner-cddlm-wg@ggf.org] On Behalf Of Paul Anderson Sent: Wednesday, February 23, 2005 12:01 AM To: 'cddlm-wg@ggf.org' Subject: [cddlm] CDL specification

Hi ...

I've been interested in trying to see if (some subset of) CDL would be appropriate for describing system configuration data. In fact, I'm arranging a short workshop in Edinburgh (April 28/29) to look at existing XML representations of system config data and compare their features - anyone interested would be most welcome ..

I'd love to attend such a workshop, because they are very much intellectually inspiring, but unfortunately these dates do not quite work for me. If you should decide to hold it later during summer, I might be able to stop by.

I'm interested particularly in the data description properties (rather than the lifecycle management), and I am sure this will raise some more detailed questions later. However ...

I am looking for a very simple language with a solid specification than could form the basis for more complex descriptions. A couple of things bother me about CDL:

1) The semantic specification is given in a rather loose way. If it intended that other people create implementations, then it is very important to have a clear semantics. I'd like to see a slightly more formal specification of this, preferably with the resolution semantics presented in some abstract way that was independent of XML-specifics like "attributes" (I can say more about the problem here if anyone is interested).

Stuart will give a less loose reply :-), but the bottom line is that even if our semantics is not strict, we believe that with a little bit of discipline in using it, we can accomplish the same objective.

2) I can't seem to determine if there is intended to be semantic equivalence with SmartFrog. If so, then I would like to see a formal statement of this in the spec, and I'd like to see the semantics presented in such a way that this can be verified (at least informally). It seems very dangerous to talk glibly about "converting between SF and CDL" if there are subtle semantic differences.

It was our intention that SF be convertible into CDL. Whether we shall succeed (if and/or how much) is to be determined through two reference implementations. We shall add this sentence into the document unless it is already clearly stated so.

3) I still don't understand how CDL is intended to be used. I had assumed that it was a low-level inter-program communication and would not be written by hand - rather it would be generated from some higher-level description. Is this the case, or will people be expected to hand-write CDL?

This version of CDL was meant to be an XML version of the SF specification, for which we were confident that it is relatively stable and would not require significant research (We were already beaten by some of the people who think that we are doing more research than it is required for a standards process). It was not meant to be primarily machine-friendly but rather serving both user- and machine-interfaces. Again, it might have not been perfect choice but we believe that it is sufficient for the version 1 of the specs. As you pointed out, there may be a need for another version some time later. Maybe this is an endeavor that you can lead since you already have some ideas and experience in the area. We would certainly welcome your input. Best regards, Dejan. PS Please continue raising comments, we really appreciate it. I would also be very much interested in reading the proceedings, notes or other outcomes of your workshop.

If it is not intended by creation by hand, then why are the templates necessary at this level - any templates could be expanded at CDL generation time. I would certainly be happier with this, because I think that the requirements of the template mechanism are not yet well understood, and there is a danger of fixing on something in the standard which is inadequate.

If it is intended for hand-creation, then this will not be suitable for use in many applications because of the difficulty involved.

All comments welcome

Many thanks

Paul