[cddlm] CDL specification

[Milojicic, Dejan S]

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 at ggf.org [mailto:owner-cddlm-wg at ggf.org] 
> On Behalf Of Paul Anderson
> Sent: Wednesday, February 23, 2005 12:01 AM
> To: 'cddlm-wg at 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
> 
> 
> 
> 
> 
> 
> 
> 
>