[cddlm] Re:Reference testing
Steve Loughran
steve_loughran at hpl.hp.com
Fri Jan 6 08:13:55 CST 2006
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?
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 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
More information about the cddlm-wg
mailing list