[cddlm] Re:Reference testing II
Guilherme Germoglio
guiga at dsc.ufcg.edu.br
Mon Jan 9 12:04:16 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?
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/cddlm-wg/attachments/20060109/69d10ac3/attachment.html
More information about the cddlm-wg
mailing list