February 2005 - cddlm-wg

Draft of deployment API
by Steve Loughran 25 Feb '05

25 Feb '05

here is the nearly-ready-to-go deployment API, please distribute for comments. Here are the outstanding issues 1. topic spaces for notifications. I think stuart may want to lay down the topicspace/topic for lifecycle events, as part of the component model. If not, I'll do it myself. We need some URLs 2. Versions of WSRF specifications to use. Unfortunately there is no "latest" set from any single working group that is consistent with the other WGs -even versions of WS-Addressing are different. 3. are all the internal CDDLM URIs and versions consistent? -steve

1 0

RE: [cddlm] CDL specification
by Stuart Schaefer 25 Feb '05

25 Feb '05

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(a)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

2 1

RE: [cddlm] CDL specification
by Milojicic, Dejan S 24 Feb '05

24 Feb '05

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

3 2

Notes from the meeting 2/23, 6am PST
by Milojicic, Dejan S 23 Feb '05

23 Feb '05

Stuart, Steve, and Dejan attended. Meeting notes: The bottom line is that we still strive for submitting all the documents to editor prior to GGF. 1. Dejan & Stuart will reply to Paul's email and try to close on the different perspectives on CDL. 2. Dejan will remind internal reviewers on the component model document. 3. Steve will post the newest deployment APIs document on Friday which will include WSDM (Dejan will forward it to WSDM experts for review). 4. Dejan will connect Steve with people who used WSDM on Dejan's projects. 5. Stuart and Jun will try to resolve remaining inconsistencies between schemas implemented by Jun and Stuart, to enable Stuart to complete his document by Monday. 6. If 5 resolved, Stuart will send deployment APIs for the "last call" on Monday, enabling us to submit to GGF editor more than a week before GGF. 7. Steve is working against the same deadlines. Thanks, Dejan. > -----Original Message----- > From: Milojicic, Dejan S > Sent: Tuesday, February 22, 2005 10:04 PM > To: 'cddlm-wg(a)ggf.org' > Subject: Reminder: meeting 2/23, 6am PST > > Hi, > > Per our agreement two weeks ago, we have a meeting tomorrow > Wed 2/23 PST at 6am PST: > > We'll use the usual phone numbers: > > Phone: +1 866-639-4732 (toll free while in US) > +1 574-948-0379 (toll & international) > Code: 2362906 (followed by a '#' sign) > > On agenda we have one most important topic: closing on the > three remaining documents. > > Thanks, > > Dejan.

1 0

Reminder: meeting 2/23, 6am PST
by Milojicic, Dejan S 23 Feb '05

23 Feb '05

Hi, Per our agreement two weeks ago, we have a meeting tomorrow Wed 2/23 PST at 6am PST: We'll use the usual phone numbers: Phone: +1 866-639-4732 (toll free while in US) +1 574-948-0379 (toll & international) Code: 2362906 (followed by a '#' sign) On agenda we have one most important topic: closing on the three remaining documents. Thanks, Dejan.

2 1

CDL specification
by Paul Anderson 23 Feb '05

23 Feb '05

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

1 0

CDL ver1.0 draft (final call)
by Jun Tatemura 20 Feb '05

20 Feb '05

Dear All, Please find the affached draft, which, I believe, is ready to submit. I also attached an answer list to comments I have not answered in the previous meeting. Best Regards, Jun Tatemura Thank you for valuable comments, which indeed improved the document quality a lot. >> 7.4.1: Value resolution is not specified for the case when >> use="optional". For instance, when a system is specified that >> extends a property list having an optional property, does the >> static resolution just omit the property? >> >> Same section: It seems that the default for the 'use' >> attribute should be required. Just the way the CDL language >> is used, every possible property is already optional. If you >> specifically mention a property, it seems like it should be >> required unless you say it is optional. >> >> 7.4.1, last example: since the default value for 'use' is >> optional, I would set the value of the attribute to required >> for the example (pending resolution of the default value). Schema annotations are used by the provider to let the user know what kind of properties are supported. Showing a property name even if it is optional is thus important. The attribute use='optional' is meaningful especially when it is combined with a type declaration. To make this point clear, I made editorial change in Section 7.4 -- the document now introduces a type declaration first (7.4.1) and then introduces an ocuurence constraint (7.4.2) with an example combining two annotations. >> 7.4.2: I don't know what a "primitive datatype of XML Schema" >> is. Does this phrase refer only to the types defined by XML >> Schema, or to any type defined using simpleType, or to any >> type defined in an XML schema instance document including >> complexTypes? Also, if you look at the example in Appendix B, >> is there any reason why the property DB in WebApp could not >> be defined as having a type of DBServer if no sub-properties >> needed to be overridden? What I meant is that data type must be either predefined in XML schema or defined somewhere so that the system can resolve. To make it clearer, I made an editorial modification in the corresponding paragraph. >> 7.5.3: I don't understand why one would want to use >> lazy="true" on a ref property. How does it change the >> resolution of the final document? 7.5.3.2 shows one example. This "lazy reference" is equivalent to the SmartFrog's lazy reference. I believe that users of SmartFrog would want to use this. >> 7.6: Parameterization looks useful at first. It makes a final >> system document fairly small. However, the statically >> resolved document ends up with a lot of duplication. Even though a prototype reference is resolved statically, value references used in parameterization may be resolved dynaically. >> 10: I don't think the choice element adds anything - this >> could just as well be a sequence element with no >> min/maxOccurs on it and have the same meaning. Using sequence >> instead of choice is usually prudent as some tools do not >> correctly handle choice. The intention was that I wanted to use the exactly same schema as WSDL's wsdl:documentation. However, I aggree that it is somewhat redundant and awkward. Thus, I have modified the schema to one uses a sequence element, which is in fact the same schema as XML schema's xsd:documentation. >> Appendix A: complexType anyType should use 'abstract' instead >> of 'abstruct'. Yes. I have corrected. >> Appendix A, propertyListType: if the intent is to allow a >> documentation child anywhere intermixed in a proerpty list >> any number of times, then using choice is OK, but I would >> remove the min/maxOccurs from documentation and any. In this >> case the text must describe the semantics of having many >> documention child elements. If the intent of a documentation >> element is to describe the following property, I think you >> should do it similar to the way WSDL/schem do it - with a >> child element of the element you are describing: >> <MyProperty type="..." lazy="..." ...> >> <documentation xml:lang="us_en">this property is really >> cool</documentation> >> </MyProperty> >> If it is not done this way, there is really no way to >> associate the description with the property. >> >> Appendix A, configuration and system: Is it the intent of >> configuration and system to have contents including >> properties and property lists, or just property lists? The >> current schema allows both, however, it seems like you only >> want to allow property lists. I am not sure what the best way >> to fix this is. It seems like you need to define different >> types for configuration/system as for any other property list. I have modified XML Schema to incorporate the above comments. However, the fix is not perfect since XML Schema does not seem to allow defining a wildcard element of a specific data type (e.g., <any type="cdl:propertyListType"/>) (I thought an abstract element can be used, but it must be combined with a substitution group, which does not seem appropriate in our case) So, I just put "documentation" in <any> which represents a property list. >> Overall: The language allows a flexible declaration of >> configuration documents. However, it is not possible to >> validate these documents in the schema validation sense. It >> feels like the configuration section is all about declaring >> types, and the system section is about an instance of a type. >> But, this is not strictly true as the configuration section >> also defines values for partial instances. What feels a >> little strange is that a system can have a document with any >> properties it wants to - even if they are not already >> declared in some way in the configuration section. What do >> these additional properties mean? Should a system be >> restricted to only declaring properties already defined in >> the configuration? If this is the case we are getting very >> close to a schema type (configuration) versus a schema >> instance (system) and should consider whether configuration >> should be abandoned in favor of using XML schema directly. >> Doing this has some advantages: ability to validate instance >> documents, obviates need for 'use' and 'type' attributes as >> well as the documentation element, uses a standard XML type >> language, allows existing tools to create and process system >> documents. Based on HP's experiences in SmartFrog, we have adopted prototype-based language semantics. One can add any additional properties to "extend" a prototype. The team believes that is one of the core features from SmartFrog applied to dynamic configuration use cases. The challenge in XML-CDL was how to combine this flexible model with XML Schema. Our solution is introducing shema annotations (Section 7.4). After (dynamic) resolution, data can be validated based on those annotations (one can develop XML Schema generator from annotation + CDL documents).

1 0

FW: revised draft
by dejan.milojicic＠hp.com 12 Feb '05

12 Feb '05

Hi Team, Per Steve's request, I am forwarding his email. Thanks, Dejan. -----Original Message----- From: Steve Loughran [mailto:steve.loughran@gmail.com] Sent: Friday, February 11, 2005 2:52 PM To: dejan(a)hpl.hp.com Subject: revised draft Dejan, Please can you forrward this to the group, ...... ------------------ This is the revised draft of the document, containing detail on endpoints, operations and faults. It is accompanied by: 1. XML schema of all types, messages 2. Stub XSD of the component model, where I have placed a couple of things that I depend upon. Stuart -you should own these and a couple more, I have placed them here to give you that ownership. Everything validates, provided you have some fixed-up declarations of SOAP1.2, and some of the other specs. All the relevant stuff is in CVS under sourceforge.net/projects/deployment; check it out and then run XML Spy against it. I spent some time in the week getting XML schema validation working under ant but gave up when it was clear coding was involved. Once I write <schemavalidate> for ant1.7 we can do this. Still todo, -The WSDL itself. I've been waiting till the schema was right before redoing it in WSRF Style. It won't take long, just a listing of which messages/responses each EPR supports. -Finalising the WS-Notification bit of the spec. I have a bit more understanding to do there first. -Adding the relevant properties for WSDM/MOWS. Stuart reassures me it doesn't add much more complexity once you've embraced WSRF. Offline for a week, not doing much (any) XML/Code work. Back Feb 21. See you all, -steve

1 0

Reminder: meeting 2/9, 6am PST
by Milojicic, Dejan S 09 Feb '05

09 Feb '05

Hi, Per our agreement last week, we have a meeting tomorrow Wed 2/9 PST at 6am PST: We'll use the usual phone numbers: Phone: +1 866-639-4732 (toll free while in US) +1 574-948-0379 (toll & international) Code: 2362906 (followed by a '#' sign) Thanks, Dejan. -----Original Message----- From: Milojicic, Dejan S Sent: Wednesday, February 02, 2005 6:47 AM To: cddlm-wg(a)ggf.org Subject: Meeting notes from 2/2/05, 6am PST Meeting by phone Attendees: Jun, Stuart, Steve, and Dejan. CDL discussion. --------------- The missing pieces: 1. Namespace URI 2. Schema Steve: it is essential that we have schema. Schema needs to be consistent with the validation. Steve will send his schema and jointly with Jun, they will produce a new schema over the mailing list. In a few days, Jun will post the schema, over the weekend. Next work will work. Stuart will own the URI resolution, he will make a proposal and then post it to OGSA. Within a week we shall close not the document and make the last call on the paper before we send it to GGF editor. Component model spec -------------------- Received comments from Steve, not from anybody else. These comments are being addressed. Stuart will modify the code base to be recursive list of URIs. If there is any better word for file name, let Stuart know. Declared discovery attributes. WSRF requires that anything that is EPR has to provide resource property documents. Can we do that with meta data exchange. This was optional. Make sure that it passes and resolves with Jun's parser. We need to do some implementations now. The only question is in Section 5.5 refeernce resolution, the way it is built now, the intermediate resoluton for CDL references, it has to go through system EPR. Either all components know all EPRs or to use URL scheme. The document is pretty much complete. Stuart will append WSDL and schema and it is ready to post it (tomorrow at latest), however, he would like to get some more comments in addition to Steve. Dejan will pass the document around. Deployment APIs --------------- Steve did not get all comments by now, others were busy with other documents. Once Steve get the Stuart documents, he will integrate them. Steve will send another update at the end of the week and integrate more of the component model. Then we can have a two weeks opoprtunity for reviewers to provide the feedback. We shall have the meeting next week, 2/9; at that meeting we shall decide whether we shall have the meeting also the week after (2/16). Thanks, Dejan.

1 0

Namespaces for GGF schema
by Stuart Schaefer 02 Feb '05

02 Feb '05

>From what I can tell.... The OGSA guys use http://www.gridforum.org/namespaces/YYYY/MM/extension as a semantic for describing namespaces. However, this is specified as application or context-dependent as stated in RFC 2396. The DAIS guys used http://www.ggf.org/namespaces/YYYY/MM/extension. I can't find consistency, but trust in the OGSA approach. I would recommend the following: 1) Use http://www.girdforum.org/namespaces/YYYY/MM/cddlm/.... as our root namespace. 2) For each document, provide no more than one namespace. So, CDL gets one, Component Model gets one, Deployment API gets one. This only affects Steve who has currently defined three or four namespaces as part of the Deployment API. Stuart

1 0