[cddlm] Re:Reference testing
Guilherme Germoglio
guiga at dsc.ufcg.edu.br
Thu Jan 5 22:47:12 CST 2006
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/cddlm-wg/attachments/20060106/d879c21c/attachment.htm
More information about the cddlm-wg
mailing list