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