[cddlm] Notes from the meeting on 6/7/2006

Milojicic, Dejan S (HP Labs) dejan.milojicic at hp.com
Wed Jun 7 08:40:54 CDT 2006


Attended: Ayla, Flavio, Satish, Guilherme, Jun, Steve. 

Update interoperability:
------------------------
UFCG: continued testing, putting the results on the page where Steve
requested. At the same point 50% testing against HP implementation
working. Still waiting on NEC endpoint testing. Almost at the same
point, could not make more progress. [Satish: CDL files that Flavio sent
do not support switch and wait; working on it and will support it very
soon; Aldo received a sample program from Guilherme, they work in
Satish's setup, so will interact with him soon regarding that] [Steve:
there will be no support until there is model; this is not a priority at
the moment]

HP: Still working on interoperability; exchanging traces with others. A
lot of things are failing, but hard to make progress when basically all
I get back is "there is something wrong", Muse to Muse implementation is
a problem, he expects that problem is on both sides. Some point
exception rather than a meaningful exception. The email is going on. The
only help would be to fix Muse to provide better stack traces. [Ayla: we
are analyzing the problem that Steve has with URLs, we do not understand
it either at the moment.] I am trying to make progress, if the things
are not working, I will send the trace and if you can submit it to your
end point, that would be useful. You can maybe debug it on your side.
[Satish: if there is any sample test program, I can simulate it on my
side] The only thing I have is the raw XML message.

NEC: Not much progress in terms of getting the component model test
against UFCG and HP, the same thing is that the CDL files do not work in
my environment and I get stack traces. We've been running with CDL files
that Flavio has sent me earlier. With respect to Steve's problem, I
could not work on the log traces he has sent, but will work on them
during this week and see whether I need to do something to have it
working; we are still working on our CDL tests needed to work with
Stuart's component model.

CDL spec status:
----------------
Public comment is closed, and I can incorporate everything. I got very
good reviews from Hiro and I will update it. There are two problems that
we have discussed: imported name space and inheritance (how it is
treated). I have sent an email on the name space resolution. Previously
we thought that it was applying only to the top level element, however
it does not solve the problem very much, because if that element has the
same roots, this local name space will not work correctly. Steve pointed
out that this is a problem. Name space import is not a good idea; the
reason why we introduced this is because of the name space conflict on
the user side, so I wanted to let user define the name space to resolve
conflict, however, this introduced complication so that conflict has to
be resolved using provider side (provider must provide the name space),
so I proposed to remove this. The providers should use unique name space
for the top element, so this is responsibility for the provider, this is
my proposal for the first problem. The second problem, is that if you
overwrite inheritance at the ref, the roots and ref must be treated as a
pair. If you put ref to overwrite the refroot, the root on the ref must
be overridden as a pair; this is the comment from Steve. Reference must
be overridden by ref value. I gave some example of inheritance that
overrides value by reference and by value. If this is ok, I will include
this into the test bed and change the spec. This is a big change, so we
need to carefully discuss it. 

Steve: these are really good changes. Namespace was troublesome cause it
was introducing all problems. The other one is the right solution too.
Will happily implement those. Namespace is easy, just drop it; for the
reference resolution, we will need some more tests. [Jun, I am also
happy with not having imported name spaces] Another beauty is that we
can cache all documents now.

Various technical:
------------------

None.

Overall planning:
-----------------

Steve has already started writing. In CVS, there is some informative
stuff, e.g. which things are hard (stack maturity, firewalls, proxies,
etc.). 

NEC (Satish): (month of) June still seems realistic, so that everyone
can test before the end of June. Still almost 90% of test against UFCG,
still missing component model test. Wrt Steve's endpoint, since he is
still working on other implementations, it remains to be seen. 

UFCG: need to implement changes that Jun proposed. For others, maybe we
can make it by the end of the month. The interoperability will  be
demonstrated between UFCG and NEC (Steve: we should also add the status
of others). We think that we are only missing the lazy support, not sure
if Jun has answered this. Wrt interoperability against others, we
believe that we are also 90% done. We have spent some time to implement
those CDLs for the component model test. However, performing test does
not take so  much time.

HP (Steve): There are two things, time to execute and time to get things
working (hard to predict, these are tangible times). As far as stuff
left to implement, I need to do expressions (we do have lazy supported
in CDL). Expressions, I am not sure how  much hard  it will be. Of
deploy API I have the core functionality (WS-Notification is lurking,
even though I hate it, it is a dead protocol). And components model,
which I haven't even started. Time to get it working, I have 15 tests
working between my endpoint and UFCG. I am making some progress there,
but it is really hard to test, it usually takes 24 hours to get feedback
(people). [Dejan: how about real-time debugging? Maybe, but it will be
really hard]. Of CDL 90%, Deployment API implemented 75%, however,
working only 60% interoperable. Component model 0%. 

Softricity:
-----------
It would be good to have their end-point up and running, but there are
also downsides, adding extra complexity at this point of time. 

NO MEETING NEXT WEEK, WILL WORK BY EMAIL.





More information about the cddlm-wg mailing list