Jun Tatemura wrote:
I think Guilherme is right in terms of interpretation of the current spec. Prototype resolution resolves the <example> as <example> <entry cdl:ref="todo">something</entry> </example> That means we cannot override a reference by specifying a value of a property. For the further example by Steve on @cdl:lazy, you need to specify @cdl:lazy="false" to turn lazyness off. What we miss is a way to override @cdl:ref and @cdl:refroot with null.. if this is an issue, we can have one of the following fixes applied to prototype resolution: [1] (explicit approach) allow @cdl:ref="" and @cdl:refroot="" to override value reference
The problem with this is that it allows the extending class to know how the parent was implemented. I might start off not using a reference for a node, but then switch to a reference later. This would break all the extending uses that overrode my value, unless they all had @cdl:ref="" every time.
[2] (implicit approach) when @cdl:ref is specified, @cdl:refroot is overridden by default value when a child node is specified, @cdl:ref and @cdl:refroot are overrideen
My preference would be to strip them both during extension if there are nested elements in the extending class. cdl:refroot inheritance lets you point at somewhere else to resolve references. <cdl:cdl> <cdl:configuration> <component> <entry cdl:ref="todo"/> </component> <c2 cdl:extends="component"> <entry cdl:refroot="c3" /> </c2> <c3><todo>value</todo></c3> </cdl:configuration> <cdl:system> <example cdl:extends="c2" /> </cdl:system> </cdl:cdl> This would create <entry cdl:refroot="c3" cdl:ref="todo"> , something that is then resolved. I dont see this as particularly useful, but it is quite obvious that it happens, because the cdl file explicitly asks for the refroot. More troublesome is if the system defined a new reference: <cdl:system> <example cdl:extends="c2" > <entry cdl:ref="value2" /> <value2>something</value2> </cdl:system> If the refroot was retained, the reference would be <entry cdl:ref="value2" cdl:refroot="c3" />, which is not resolveable.
Another issue is if the above description is allowed - the spec says: "Value references MUST NOT be placed in an element that has child elements" (7.3.1) I think (I wanted to mean) this is "an element that has child nodes" then the above description should be failed.
The test cddlm-cdl-2005-02-invalid-0004 already checks for a failure here: <t:operation id="cddlm-cdl-2005-02-invalid-0004"> <t:description> illegal inclusion of text under a reference </t:description> <t:in> <ct:documents> </ct:documents> <ct:resolve> <cdl:cdl> <cdl:configuration> </cdl:configuration> <cdl:system> <app> <hostname>localhost</hostname> <database cdl:ref="hostname" >illegal text</database> </app> </cdl:system> </cdl:cdl> </ct:resolve> </t:in> <t:out> <ct:failed/> </t:out> </t:operation> We could add tests for a <!-- comment --> child node as well. -Steve