Meeting notes: CDDLM meeting on Wednesday January 4th
Attendees: Ayla, Flavio, Guilherme, Stuart, and Dejan
1. Update on reference implementations
UFCG is on track with their reference implementation. There are questions about some of the problems that Steve has raised with respect to CDL and there are some remaining tests that have not been completed, but the team believes that they will complete their reference implementation before GGF. Softricity will complete Deployment API tests in the forthcoming week and then attack component model. Stuart believes that they will have completed reference implementation before end of January.
2. Planning GGF16 in Athens
Stuart, Steve, and Dejan are confirmed to attend; Ayla and her team will not attend. It is believed that Jun will attend, but this still needs to be confirmed. UFCG team may prepare the demo for someone else to present it at GGF (Steve, Jun?), if they are available given that they will be preparing their own demonstrations. A fallback solution is to do presentation (slides) instead.
3. Planning OGSA F2F session
There is an OGSA F2F next week (1/17) with 2 preparation meetings beforehand. Dejan will attend F2F, Stuart will either attend or dial-in.
4. Various
Regular meeting will take place next week. Thanks, Dejan.
-----Original Message----- From: owner-cddlm-wg@ggf.org [mailto:owner-cddlm-wg@ggf.org] On Behalf Of Milojicic, Dejan S (HP Labs) Sent: Wednesday, January 04, 2006 12:16 AM To: cddlm-wg@ggf.org Subject: [cddlm] Reminder: Regular Meeting Tomorrow, Wednesday January 4th
Hi,
We shall have a regular meeting tomorrow/today, Wed 1/4/06, at 6am PST. We will use our usual numbers:
+1 866-639-4732 (toll free while in US) Code 2362906 (followed by a '#' sign) +1 574-948-0379 (toll & international)
Agenda:
1. Update on reference implementations 2. Planning GGF16 in Athens 3. Planning OGSA F2F session 4. Various
Thanks,
Dejan.
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 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. 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. Finally, is it an error to have cdl:refroot on a node without a cdl:ref attribute? 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
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,. -steve
HI XML namespace is a source of headache, when we need to import a fragment of XML from a document to document.. My interpretation is that, when we say @cdl:refroot has a QName value, it should be so in description time, not in resolution time. That is, the prefix must be interpreted where it is written. An implementation headache is that we must carry over the namespace context from the original template. <cdl:cdl > <cdl:configuration > <p1:local xmlns:p1="http://cddlm.org/prefix1"> <newvalue>prefix1</newvalue> </p1:local> <p1:local xmlns:p1="http://cddlm.org/prefix2"> <newvalue>prefix2</newvalue> </p1:local> <node xmlns:p1="http://cddlm.org/prefix1"> <value cdl:ref="/newvalue" cdl:refroot="p1:local" /> </node> <toplevel cdl:extends="node" xmlns:p1="http://cddlm.org/prefix2"> </toplevel> </cdl:configuration> <cdl:system > <app> <user cdl:ref="value" cdl:refroot="toplevel"/> </app> </cdl:system> </cdl:cdl> cdl:extends at toplevel should be resolved to something equivalent to: <toplevel xmlns:p1="http://cddlm.org/prefix2"> <value cdl:ref="/newvalue" cdl:refroot="p1:local" xmlns:p1="http://cddlm.org/prefix1"/> </toplevel> Thanks, Jun Steve Loughran 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,.
-steve
Jun Tatemura wrote:
HI
XML namespace is a source of headache, when we need to import a fragment of XML from a document to document.. My interpretation is that, when we say @cdl:refroot has a QName value, it should be so in description time, not in resolution time. That is, the prefix must be interpreted where it is written.
I agree. I am starting to make an implementation notes doc in the documents/cdl directory on sourceforge where we can add clarifications.
An implementation headache is that we must carry over the namespace context from the original template.
Yes, that is what I do. when I create a reference path to resolve at run time, I cache the namespace declarations in scope at parse time for later use during resolution. The XML library I use (Xom) doesnt make this very public; its an O(depth*namespaces) operation for every node, so O(depth*namespaces*lazy nodes) for a full system.
<cdl:cdl > <cdl:configuration > <p1:local xmlns:p1="http://cddlm.org/prefix1"> <newvalue>prefix1</newvalue> </p1:local> <p1:local xmlns:p1="http://cddlm.org/prefix2"> <newvalue>prefix2</newvalue> </p1:local> <node xmlns:p1="http://cddlm.org/prefix1"> <value cdl:ref="/newvalue" cdl:refroot="p1:local" /> </node> <toplevel cdl:extends="node" xmlns:p1="http://cddlm.org/prefix2"> </toplevel> </cdl:configuration> <cdl:system > <app> <user cdl:ref="value" cdl:refroot="toplevel"/> </app> </cdl:system> </cdl:cdl>
cdl:extends at toplevel should be resolved to something equivalent to: <toplevel xmlns:p1="http://cddlm.org/prefix2"> <value cdl:ref="/newvalue" cdl:refroot="p1:local" xmlns:p1="http://cddlm.org/prefix1"/> </toplevel>
OK
participants (3)
-
Jun Tatemura -
Milojicic, Dejan S (HP Labs) -
Steve Loughran