Paul, I had promised to Dejan I would respond to your earlier comment, but I will try to respond here as the thread has continued in the same vein. 1) Semantics. A bit of both sides of the argument. The CDL language draws its main semantic definitions from the SmartFrog project. SmartFrog has fairly well defined semantics. The CDL must define its operational terms in some way. It can do so using BNF, UML, XML or whatever, as long as it has made clear how it is to be used. If you look at a project like RDF, the RDF semantics primer was just released, years after the definition of the language specification. Many people have done great injustice to RDF in using it in bizarre and incompatible ways. The other side of the argument. If the CDL has not disambiguated important or edge scenarios, the likelihood of what you have proposed is very high. Reading others code won't solve the problem, as different implementations may solve the situation differently. A language must be clear about what is and is not strictly enforced. In reference to your example, I posed that exact question to Jun, the author of the CDL specification some months ago and will ensure that it is properly dealt with in the final release of the CDL spec. The component model relies on preservation of lexical order. SmartFrog did not have this limitation, as its templating language was much more freely expressed. There may be other semantics that are undefined or not clearly defined. I am not sure. Do you have any other examples? 2) Languages like system configuration grammars are hard for people to write. People don't think this way. Tooling is typically very important for the successful implementation of any system. Vanish from HP was very helpful in showing the BPEL example. BPEL is a very rich language, but almost impossible to write by hand due to its complexity. However, it is very clear how to create a tool that can write well-formed BPEL, and many vendors and independents have done just that. The purpose of CDL is to allow many contributors to a system definition. I am not sure that people will directly author CDL. On my side, we are implementing higher level tooling that can use CIM and CMDBs to derive a well-formed description, then parse down to CDL. It works quite nice. If you look at a language like DCML, it is written using RDF triples to use an ontology of system descriptions. Is that easier? 3) It would be helpful for me to understand what you consider research features. Working Groups don't do research. We write specs based on experience and implementations. Regards, Stuart -----Original Message----- From: Paul Anderson [mailto:dcspaul@inf.ed.ac.uk] Sent: Thursday, February 24, 2005 2:42 AM To: Milojicic, Dejan S Cc: Paul Anderson; cddlm-wg@ggf.org Subject: Re: [cddlm] CDL specification

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

Many thanks for the response Dejan. This is pretty much what I had expected - I do understand the pragmatic reasons behind these decisions, but perhaps I can just summarise my concerns .. 1) If people are expected to make independent implementations of a langauge, they are much more likely to work correctly if the the language is defined by a written semantics, rather then by a reference implementation where people have to guess the significant parts of the semantics by reading someone else's code (for example, "does the order of these elements matter"?) 2) Certainly in the system config area, people at many different levels of skills will be expected to make contributions to an overall configuration, and we have identified the difficulty of learning to use the language as a major barrier to the uptake. Misconfiguration due to language confusion is also a major source of configuration errors. Hand-writing CDL is going to be significantly more difficult than the languages that we have considered previously. I would like to have seem a simpler language which standardised on the well-accepted basics, and left out (or made optional) the more "research"-oriented" features which could be layered on top later. I'll definitely keep you in touch about the workshop outcome, and I'll probably have more questions before then ... :-) Many thanks Paul