[cddlm] Re:Reference testing II

[Steve Loughran]

I'm on holiday/vacation this week, and will exclude myself from the 
phone conf, but I'm going to answer this email briefly instead of 
waiting a week.

Guilherme Germoglio wrote:

> 
>      >
>      > 6. The ../valid/set_04_import/cddlm-cdl-2005-04-0003 test:
>      > One document is added with a different name from it's been
>     imported. So it
>      > can't be found.
>      >
>      > The original:
>      >
>      > <t:in>
>      >       <ct:documents>
>      >         <ct:document uri=" http://cddlm.org/chain-target.cdl">
>      >           <cdl:cdl>
>      >             <cdl:configuration>
>      >               <WebServer>
>      >                 <hostname>localhost</hostname>
>      >                 <port>80</port>
>      >               </WebServer>
>      >             </cdl:configuration>
>      >             </cdl:cdl>
>      >         </ct:document>
>      >         <ct:document uri="http://cddlm.org/chain-source.cdl">
>      >           <cdl:cdl>
>      >             <cdl:import location=" chain-target.cdl"/>
>      >           </cdl:cdl>
>      >         </ct:document>
>      >       </ct:documents>
>      >       <ct:resolve>
>      >         <cdl:cdl>
>      >           <cdl:import
>      > location="http://cddlm.org/chain-source.cdl"/
>     <http://cddlm.org/chain-source.cdl"/><http://cddlm.org/chain-source.cdl%22/>
>      >           <cdl:system>
>      >             <MyServer cdl:extends="WebServer">
>      >               <hostname>www.cddlm.org
>     <http://www.cddlm.org></hostname>
>      >             </MyServer>
>      >           </cdl:system>
>      >         </cdl:cdl>
>      >       </ct:resolve>
>      >     </t:in>
>      >
> 
>     According to the description, its a test at how relative imports are
>     handled. That's why the required=false thing is set at the top
> 
>     The test is to see if a doc whose location is
>     http://cddlm.org/chain-source.cdl can import a doc at chain-target.cdl
>     and have that expanded to http://cddlm.org/chain-target.cdl
>     <http://cddlm.org/chain-target.cdl> before
>     conversion takes place.
> 
> 
> Sorry, Steve, can you explain better?

I'm testing to see if imports are relative. If you import a document at 
a given URL, is that URL remembered, so that relative URLs in import 
statements are resolved against the base URL of the document.


  > Now, resuming the feedback for newer tests:
> 
> 1. ../set_02_references/cddlm-cdl-2005-02-0012: It has the same 
> "toplevel/refroot" problem this time in cdl:configuration node.
> 
> Original:
> 
>  <cdl:cdl>
>           <cdl:configuration>
>             <secondary>
>               <nested>
>                 <value>12</value>
>               </nested>
>             </secondary>
>             <toplevel cdl:ref="/secondary/nested/value"/>
>           </cdl:configuration>
>           <cdl:system>
>             <app>
>               <user cdl:ref="." cdl:refroot="toplevel"/>
>             </app>
>           </cdl:system>
>  </cdl:cdl>
> 
> Sugestion:
> 
>   <cdl:cdl>
>           <cdl:configuration>
>             <secondary>
>               <nested>
>                 <value>12</value>
>               </nested>
>             </secondary>
>             <toplevel cdl:refroot="secondary" cdl:ref="/nested/value"/>
>           </cdl:configuration>
>           <cdl:system>
>             <app>
>               <user cdl:ref="." cdl:refroot="toplevel"/>
>             </app>
>           </cdl:system>
>         </cdl:cdl>

You are right. Feel free to change it this week, or I will do it next week.


> 2. ../set_02_references/cddlm-cdl-2005-02-0016: This is an interesting 
> one. The test has this description:
> 
>       Interaction of extends and resolves.
> 
>       This test asserts that a refroot qname is resolved
>       in the context of the original namespace, not that
>       of the node into which any extends has taken place.
> 
>       That is: "extends" doesnt break any absolute references
>       you have elsewhere
> 
> But don't you think that the fact that some attributes have a special 
> treatment (such the xmlns*) breaks the algorithm in p12-14 of the 
> specification? This way, redefined attributes replace the inherited 
> attributes (as the algorithm specifies) unless they are xmlns*, which 
> are attributes too.
> 

xmlns declarations are trouble, especially DOM which treats them as 
simple attributes. Xom, which I am using, has extra special treatment of 
them; there is a method to list all ns declarations in scope, rather 
than just local ones, which is what I want to remember and resolve. I am 
busy trying to persuade the Xom developer that this method should be 
public...

The more I delve into namespaces and CDL, the more I find trouble. We 
dont have much in the way of explicit coverage of namespace issues in 
the spec, but most of the problems I am encountering are related to 
them. I will look at the relevant pages of the spec until next week. 
Then maybe at next weeks phone conf we can talk about these issues 
(which I'm filing on the ggf.org tracker).

-steve