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