[cddlm] Sourceforge and a new CDL resolution bug in my implementation.

Steve Loughran steve_loughran at hpl.hp.com
Mon May 22 07:56:30 CDT 2006


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





More information about the cddlm-wg mailing list