Guilherme Germoglio wrote:
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.html
oh, thank you for those details.
I like the first one, that covers how to handle qnames in a world with xmlns="something".
This is very related to the q. on the CDL spec from last june,
https://forge.gridforum.org/tracker/?aid=1545
I the XPath policy shows how to resolve it in this situation too, namely to require a prefix on an cdl:extends="tns:something" declaration, if the default xmlns is set to the same uri as tns:
This also affects cdl:cdl/@cdl:targetnamespace; there isnt really much point having a target ns declaration when you need to be explicit about the ns of all extends and paths.
-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.
OK. Will add a valid test here.
If it is valid, must the refroot refer to a valid node?
As the resolution only occurs if cdl:ref exists, I think refroot must be valid only in this case. Added as CDL tracker item https://forge.gridforum.org/tracker/?aid=1714
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.
I see. we could do one that imports a parent though, that should break things.
This is the revision.
<cdl:system> <app> <hostname>localhost</hostname> <database > <server cdl:ref=".." /> </database> </app> </cdl:system>
As an aside, I am not going to do anything sophisticated to catch recursion here. I will rely on stack overflows instead.
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.
yeah, I have some funnies with xmlns propagation too. I've moved the declaration down.
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.
you are correct. Will fix. [Pause]. Ok, corrected, but see the discussion below on whether system nodes can act as top level lists at all.
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.
thanks. must have been an accidental typo on my part.
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?
I had implemented system node extension, but then turned it off.
7.1 "a property list is called a toplevel property list when it is a child of a cdl:configuration element".
7.2.1 "Only a top level list, which has a unique name, may be the destination of a prototype element."
Now, looking more closely, S7.3.1 says that the dest of a cdl:refroot must be a top-level property list too. So in fact, the test 2005-02-0005 is still invalid after correction, because it is trying to use something else in cdl:system as a refroot:
<cdl:system> <app> <hostname>localhost</hostname> <database cdl:ref="/hostname"/> <user cdl:ref="." cdlrefroot="toplevel"></user> </app> <toplevel>username</toplevel> </cdl:system>
I will move it to being an invalid test, because, unless S7.1 is changed.
I will add a tracker to this so that Jun can clarify it.
https://forge.gridforum.org/tracker/?aid=1715
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>
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 before conversion takes place.
Sorry, Steve, can you explain better?
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.
no, no, dont apologise, I am grateful for the feedback. It is through these tests that we get to coordinate our understanding of things. Initially they implement Jun's knowledge and my inevitable misinterpretation of the specs; you bring different knowledge to the group (like the XPath stuff) and really help us.
-steve
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> 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. Guilherme