Dear Team, Please find the attached file that lists comments/feedbacks with my answers and action lists (I apologize the list is not complete) which I would like to discuss on the call tomorrow. Thank you very much for comments and feedbacks. Best Regards, Jun Tatemura ---- From Paul Anderson ------------- 1) 7.2.1 - there doesn't seem to be an explicit statement of how the "extends" resources on sub-elements are resolved (as in the given example). I'm assuming that that "extends" attributes on any sub-elements are evaluated before the "extends" attributes on the element itself - is this correct? 2) 7.2.2 (1) - I'm assuming that any "extends" attributes on sub-elements of n' are evaluated at this time (as above). Is this correct? [Answer] Since prototype reference resolution merges only immediate children (resolution not applied to descendants recursively), the order of resolution between ancestors and descendants does not matter. Note that children do not import attributes from the prototype children For example, suppose we have three trees a1(b1(c1,d1),e1) (a1 has children b1 and e1, b1 has children c1 and d1) f2(b2(c2,g2),h2) i3(c3,g3,j3) k4(c4,d4) and a1 extends f2, b1 extends i3, b2 extends k4. If we resolve a1 then b1: a1(b1(c1,d1),h2,e1) a1(b1(c1,g3,j3,d1),h2,e1) If we resolve b1 then a1: a1(b1(c1,g3,j3,d1),e1) a1(b1(c1,g3,j3,d1),h2,e1) resolution of b2 (with k4) does not affect to the final result at all regardless of its timing (since b2 subtree is completely replaced by b1 subtree) [Proposed Action] Add a sentence that state the order does not matter. 3) 7.2.2.1 (2.2) I think the e should be e' ? [Answer] Yes. it should be e' [Proposed Action] correct it 4) In the "hierarchical prototype reference" example on page 16, am I right in thinking that the first extends="WebServer" is redundant (in this case)? This is just to confirm my understanding of the semantics - things might be different, for example if (1) and (2) above were different. [Answer] Yes, the first one (/AppPlatform/WebServer/@cdl:extends) is redundant (has no effect) for /MyApp. Since children do not inherit attributes from prototype children, we need the second one (/MyApp/WebServer/@cdl:extends) to let /MyApp/WebServer have default children. 5) Are the template/reference semantics identical to SmartFrog? I've probably missed the discussions on "why" certain things are being done the way they are, but it would be really helpful to have some indication of this where there are important reasons. I was particularly interested in .... [Answer] Yes, our discussion done before is mising in the specification itself. I think we may want a separate informational document -- probably what we may call "CDDLM Primer" that covers design principles, integration, and use cases of our three pieces of CDDLM specification. It would wrap up our discussions and efforts on ver 1.0 started since the Foundation document. 6) It doesn't look like there is any multiple inheritance - is this correct? Was it considered? [Answer] No we have not considered multiple inheritance. 7) The fact that inheritance applies to the immediate children only seems to cause some difficulties - was there some specific reason for doing things this way? [Answer] This decision has been made based on consistency with SmartFrog. In addition to this reason, I also had some concern on deep inheritance: - The user needs to be aware of deep tree structre to expect the resolution result. This may cause unexprected inheritance. - How can we replace a subtree of prototype with "null"? We can only replace leaf values. 8) Is it possible to separate the template resolution phase from the other phases? ie. Could I write a transform that took an arbitrary CDL document and generated a semantically equivalent document that contains no templates? If this is the case, why would would I not want to resolve out all the templates before deploying the document? [Answer] Yes. The template resolution can be completely preprocessed before any other type of resolution (except resolution of "import", of course). The reason why this resolution is not been done on the requesters side is, I guess, we think resolution processing can be a part of services offered to the requester. (of cource, the requesters can do it by themselves if they want). --From Bryan Murray (via Dejan)---- [Comment] I don't think section 3.3 adds anything to the spec. If SmartFrog CDL or some other CDL is also published from CDDLM, then there is value in keeping it. However, if these are just other proprietary front-end languages that have no bearing on this spec, I would remove this section. [Answer] I have no strong opinion on that. I would suggest we can remove it so far and put it later again in "CDDLM Primer" (or similar document that wraps up entire CDDLM pieces) [Proposed Action] solicit opinions from others in WG [Comment] I did not understand part of the pseudo-schema used in section 6. Are the documentation and property list elements tied together somehow? Does a property list element contain either a documentation element or some property elements - this is what the schema says now? My guess is that you want to say that a property list contains an optional documentation element and any number of property lists. Also, a property list can also contain an optional documentation element. To do this I think you could change PropertyListType to use sequence instead of choice and remove the min/maxOccurs. The pseudo-schema would look like this: <cdl:configuration> <cdl:documentation ...>xs:any</cdl:documentation> ? <!-- PropertyList --> * </cdl:configuration> ? If you want to explicitly require configuration to only hav property lists and property lists to be able to have either properties or property lists, you will need to types. [Answer] I tried to mean that cdl:documentation can be inserted anywhere...I will think about better description. [Comment] Section 7.2.2.1, #2.1: Should it be the same name and namespace? If it is just the same name, then all property names would have to have a unique local name and I think youwould run into a lot of problems. [Answer] Yes, it should be namespace-aware. [Action] Add a clarification sentence. [Comment] Section 7.2.2.1, #2.2: I the the italic e should be e'. [Answer] Yes, it should be so (as mentioned above) [Comment] Section 7.2.2.1: instead of saying append to 'last' of node list, you might want to say 'end' of node list. [Answer] This meant "end" or "tail" (as Steve suggested) [Proposed Action] change it to either "end" or "tail" [Comment] 7.2.3: Statement towards bottom of p 14: "When a child element is overridden, its value is fully replaced." This means that even if you want to tweak a single property, you need to re-write the entire property list. This could be a burden for large property lists. [Answer] This is related to Paul's previous comments: why not inherit deep structure? The main reason was I tried to make the language semantics as consistent with SmartFrog as possible. For this design choice, we rely on the fact that SmartFrog is working well without that. [Comment] 7.2.3, para starting "Another way to achieve hierarchical ...": This is not obvious, I don't know if I would advertize it or not. Its hard for me to wrap my mind around this - it seems to be warping inheritance. [Answer] This is a consequence from the design choice mentioned above. [Comment] Figure 4: The ref and refRoot attributes seem to be very complicated. How about using the cdl:configuration (or cdl:system) node as the root. This way 'a' does not become '/' - it would be '/a' which makes more sense to me. And 'b' nodes can be accessed just as easily without needing refRoot. [Answer] I did not take that design choice since it will be also complicated when combined with inheritance. For example: <a><b cdl:ref="/a/c"/><c>..</c></a> <d cdl:extends="a">...</d> should d be resolved to <d><b cdl:ref="/a/c"/>...</d> or <d><b cdl:ref="/d/c"/>...</d> ? ---- From Keisuke Fukui - We will appreciate a more detailed explanation for each object in the figure. For example, what are the meanings of the term "events" and "observer" illustrated in figure 5 in chapter 11? [Answer] After adding detailed resolition procedures in Section 7, we may not need Section 11 anymore (historically, this section has been itroduced to make the section structure similar to the SmartFrog document...). [Proposed Action] Shall I remove Section 11 and move some of description into Section 7? - A glossary might be helpful to readers. For example, the word "property" is first used in section 3.2.1, but I was not sure what it represents in the CDL context until section 5.1. And the word "CDL" is used after section 6.1 with no explanation. [Answer] I would handle word inconsistency/ambiguity issues by revising instead of adding a glossary. I would apreciate if someone points out more terminology issue examples. [Proposed Action] I may need to revise Section 3. - We will appreciate the conceptual modeling written in section 3.1. Are the concepts (e.g. Configurable Components, System, ...) used throughout the series of CDDLM specifications? If so, a more detailed explanation is expected. It must be a great help for understanding the entire picture of CDDLM. I believe it should be here rather than in separate documents. I needed to put a bit abstract model so that it will be consistent with other two specs coming later. A concrete model of CDDLM should be written in a document like "CDDLM Primer"... [Proposed Action] Now that I have two document draft, I may revise Section 3. - The language requirements are defined in each released document (foundation document / SF-CDL / XML-CDL) and they are slightly different each other. We will appreciate a bit clarification or justification for it. [Answer] Requirements to SF-CDL and XML-CDL are by definition different (that's why we have two languages)... It may be a good idea to revisit these requirements issue, though. - The existing CDL specification defines the generic mechanism for inheritance and reference, but who defines the standard vocabularies to describe services and resources? We are not sure if configuration descriptions can be interoperable without standard vocabularies. [Answer] Vocabularies must be defined and standardized for each application domain. That is way beyond the scope of CDL itself. - In chapter 2 and 3, the relationship between XML-CDL and SF-CDL is explained prior to the detailed explanation of configuration description. Unless they are being used together, I guess it may be better placed in appendixes. The main part of the document should be standalone I believe. [Answer] As answered to Bryan above, we may remove it and put it to another document. -------------------- From Steve (not covered all...)----- - Notation of '?' and '*' in Section 6 I will add explanation of notation just as other WS related spects do. - semantics of '/..'? The path expression must be a subset of XPath 1.0. Since there is no parent node of the root node, it should not be a varid path. - procedure of Import I would limit URIs to be absolute