Steve Loughran wrote:
I've just checked in
-more valid (non-lazy) reference tests -new invalid non-lazy reference tests -the first refroot tests.
These tests are encoding my (mis?)-understanding of the ref and especially refroot bits of the spec. Please check and advise me of any errors.
The fun ones are refroot related. I believe the following is valid (cddlm-cdl-2005-02-0010)
<cdl:cdl > <cdl:configuration xmlns:test1="http://cddlm.org/test1.cdl" > <test1:toplevel> <test1:value>username</test1 :value> </test1:toplevel> </cdl:configuration> <cdl:system xmlns:t1=" http://cddlm.org/test1.cdl"> <app> <user cdl:ref="t1:value" cdl:refroot="t1:toplevel"/> </app> </cdl:system> </cdl:cdl>
This uses qnames and resolves against something in cdl:configuration
I am now starting to think that XML is invalid. It all depends upon where QName prefixes are evaluated.
It may be legit to use xmlns prefixes that are only defined in the context of the destination reference, e.g. <user cdl:ref="test1:value" cdl:refroot="t1:toplevel"/>
I am going to read up on Xpath and think about this some more.
What is everyone else doing regarding QName prefix lookup during resolution? There is no coverage of the problem in the specification itself,.
As we are using the xalan API to resolve this XPath queries, our only resolution occurs when the prefixes are only defined in the context of the destination reference, raising an exception case it doesn't find the given prefix. Besides that, XPath provides some non-trivial ways to deal with namespaces: http://www.xml.com/pub/a/2004/02/25/qanda.html http://mail.gnome.org/archives/xml/2002-December/msg00188.htmlfelizfe
-steve
I also believe the following should resolve (cddlm-cdl-2005-02-0006)
<cdl:cdl> <cdl:system> <app> <user cdl:ref="." cdl:refroot="toplevel"/> </app> <toplevel>username</toplevel> </cdl:system> </cdl:cdl>
Here the refroot is the name of something in the local namespace in the system, and we are extracting the "." node from it. This is important: it means that you can have as a refroot more property lists than you can use cdl:extends= with, as that only let you refer to stuff in cdl:configuration.
We made that way too.
II believe that duplicate refroots should fail, such as in cddlm-cdl-2005-02-invalid-0008
<cdl:configuration> <toplevel>username</toplevel> </cdl:configuration> <cdl:system> <app> <user cdl:ref="." cdl:refroot="toplevel"/> </app> <toplevel>clash</toplevel> </cdl:system> </cdl:cdl>
All the spec says is that refroot "is the name of a top level property list". It does not say that this root must be the name of a unique property list.
It's better to fail - this way we will know the behavior of all implementations.
Finally, is it an error to have cdl:refroot on a node without a cdl:ref attribute?
I think not. The resolution cares about the "cdl:ref". The "cdl:refroot" attribute in a node without "cdl:ref" would be an attribute as any other.
If these and the other new tests fail either we have different interpretation of p17-19 of the CDL specification, which needs to be resolved now.
-steve
Finally, about the other tests (I'll comment other tests too, not only those for references): 1. The invalid reference test: cddlm-cdl-2005-02-invalid-0002.xml states directly recursive reference for: <cdl:cdl> <cdl:configuration> </cdl:configuration> <cdl:system> <app> <hostname>localhost</hostname> <database cdl:ref="database" /> </app> </cdl:system> </cdl:cdl> But the resolution algorithm (p18-19) does not specify that the attributes from the referenced node must be copied, only its children - so the "cdl:ref" from database would not be copied and eventually the recursive reference will not occur. 2. Something strange occured in cddlm-cdl-2005-01-0006 (../valid/set_01_extends). Our engine doesn't recognize the prefixes that were declared on the first element of the XML but are used inside the cdl and raises a parser error. Maybe the XML library we're using does not stores the prefixes' declaration when the "cdl:cdl" node is extracted for the tests - we fixed it declaring those prefixes again on the "cdl:cdl" node. 3. The valid reference test cddlm-cdl-2005-02-0005: <cdl:cdl> <cdl:configuration> </cdl:configuration> <cdl:system> <app> <hostname>localhost</hostname> <database cdl:ref="/app/hostname"/> <user cdl:ref="/toplevel"></user> </app> <toplevel>username</toplevel> </cdl:system> </cdl:cdl> As we can see on figure 3 on p18 from CDL document, the slash ("/") already is the "root node" (a in the figure 3; app node in the case of the databasein the cdl above). So the ref should be only " /hostname" instead of " /app/hostname". And the user ref should use cdl:refroot to reference toplevel. So, the cdl should be something like this: <cdl:cdl> <cdl:configuration> </cdl:configuration> <cdl:system> <app> <hostname>localhost</hostname> <database cdl:ref="/hostname"/> <user cdl:refroot="toplevel" cdl:ref="."></user> </app> <toplevel>username</toplevel> </cdl:system> </cdl:cdl> 4. The cddlm-cdl-2005-02-0008 from valid reference tests is not well-formed. Its first character is "7". I already commited this one. 5. The ../invalid/set_01_failures/cddlm-cdl-2005-01-invalid-0002.xml has its id incorrect: cddlm-cdl-2005-01-invalid-0001 instead of cddlm-cdl-2005-01-invalid-0002. Besides that, it states it is only allowable to extend a configuration node, not a system node. We did not find in specification this restriction, is this an implementation decision? 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%22/>
<cdl:system> <MyServer cdl:extends="WebServer"> <hostname>www.cddlm.org</hostname> </MyServer> </cdl:system> </cdl:cdl> </ct:resolve> </t:in> I think it must be: <t:in> <ct:documents> <ct:document uri="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%22/>
<cdl:system> <MyServer cdl:extends="WebServer"> <hostname>www.cddlm.org</hostname> </MyServer> </cdl:system> </cdl:cdl> </ct:resolve> </t:in> Sorry for such a huge mail. I've just noticed more tests were checked in. I'll see them and send a feedback, if necessary. Guilherme