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
