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 [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 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. I will appreciate your comments on the above two issues Thanks, Jun Steve Loughran wrote:
ooh, this is worrying.
You cannot say 'drop all cdl: attributes' because there are some things, particularly, cdl:type, that you do want.
Its only cdl:ref and cdl:refroot attributes that must be stripped when you extend something (and, presumably of cdl:lazy). Without that, you cannot extend any attribute that is bound to a reference, because that reference binding is retained.
You dont want any of the following to have the parent stuff merged
refroots:
<component> <entry cdl:ref="todo" cdl:refroot="a:newroot" /> </component>
<c2 cdl:extends="component"> <entry cdl:ref="value"> <value>7</value> </c2>
lazy links <component> <entry cdl:ref="todo" cdl:lazy="true" /> </component>
<c2 cdl:extends="component"> <entry cdl:ref="value"> <value>7</value> </c2>
Jun, what do you think?
-steve
Guilherme Mauro Germoglio Barbosa / Projeto Ourgrid - Projeto Ourgrid/LSD wrote:
Hi Steve,
I think your implementation is correct (not the test). In the specification, the inheritance of elements algorithm (7.2.2.1) states:
/7.2.2.1 Inheritance of Elements Inheritance of elements from a node n' to a node n is defined as follows: 1 Let N an empty node list. 2 For each child element e' of n' from the first element to the last element: 2.1 If the node n has child elements E = {e1, e2,...} that have the same name as e' 2.1.1 If N does not contain an element that has the same name as e': *2.1.1.1 For each element ei in E in the document order, append ei to the end of N. _Inherit attributes from e' to ei._* 2.2 Otherwise, append e' to the end of N. 3 For each child element e of the node n from the first element to the last element: 3.1 if the element e' does not have a child element that has the same name as e, append e to the end of N. 4 Replace n's children with the nodes in N./
And your code, based on what you said on the e-mail, does what was underlined above.
Guilherme
Steve Loughran wrote:
Sourceforge is back up, but you need to check out everything again in a new directory tree.
Incidenally I just found a little thing my CDL impl. can't resolve
<cdl:cdl> <cdl:configuration>
<component> <entry cdl:ref="todo"/> </component>
<c2 cdl:extends="component"> <entry>something</entry> </c2>
</cdl:configuration> <cdl:system> <example cdl:extends="c2" /> </cdl:system> </cdl:cdl>
This fails on my impl, with the entry being undefined.
<example xmlns=""> <entry cdl:ref="todo">something</entry> </example>
I'm clearly not scrubbing cdl:ref stuff when I extend an element, when in reality I should strip that and cdl:refroot.
This is now a new test: /org/ggf/cddlm/files/cdl/valid/set_02_references/cddlm-cdl-2005-02-0023.xml
Its interesting to see that I can still find problems in my code while writing more CDL files. If anyone has more example CDL Files, especially those that work on their system, please add them as CDL tests just to give us as broad a set of tests as possible.
-Steve