January 2006 - cddlm-wg - lists.ogf.org

Re: [cddlm] Re:Reference testing II
by Guilherme Germoglio 10 Jan '06

10 Jan '06

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

2 1

[ogsa-wg] Proposed agenda for <DATE> call
by Hiro Kishimoto 09 Jan '06

09 Jan '06

Hi all, I hope you and your family had a good holiday break and are looking forward to the new year. The following is a proposed agenda for OGSA-WG telecon on Jan. 9th Monday from 4pm to 6pm (CST). The dial-in number for Monday; Free: +1-866-639-4741 Toll: +1-574-935-6703 PIN: 8980700 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0109 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (Dec. 19) https://forge.gridforum.org/projects/ogsa-wg/document/minutes20051219/en/1 Do we have Jan. 11th telecon, since several people will be at GFSG F2F meeting? Agenda bashing 2) CDDLM-WG joint call (60 min) Jem has uploaded the revised version to the GridForge. - http://tinyurl.com/aez86 Look forward to proofread and tracker verification. (1) Deployment and configuration section break-down > == Proposed list of sections == > > 3.1 Provision (Deploy) an application on an existing BES container > (The application can then be used to instantiate a BES activity. > Mostly what is now 3.2 in EMS Architecture composition.) > > 3.2 Provision a BES container > (What is now 3.1 in EMS Architecture composition) > > [Both 3.1 and 3.2 assume that the 'level' of the BES container is > pre-determined and fixed. See below.] > > 3.3 Using ACS do 3.1 > > 3.4 Using ACS do 3.2 > > [Both 3.3 and 3.4 assume that the 'level' of the BES container is > pre-determined and fixed. See below.] > > 3.5 Add time predictions to provision 3.1 and 3.2 by a deadline > Using a deployment estimation service (perhaps based on > historical data, etc, but how the estimation is done is > out-of-scope.) Possibly requiring reservations. > > [3.5 assumes that the 'level' of the BES container is pre-determined > and fixed. See below.] > > 3.x Determine dynamically the optimal level of 'BES container' in the > system and provision containers appropriately depending on > workload etc > may depend on analysis of the entire application CDL (down to > hardware) for the entire workload of the system; use > deployment time predictions; etc > > <<Version 1 of the document could just cover scenarios 3.1-3.5 and > discuss 3.x as future work. Otherwise need to breakdown 3.x further.>> > == (2) - Deployment versus provisioning requirements > (Or, where to 'cut' the CDL tree. Above the 'cut' point is > deployment---assumed to be a relatively 'light' operation---and > below is provisioning---assumed to be more heavy-weight.) > - Deciding the cut point is orthogonal to CDDLM---it is policy or > best practices and is therefore a system choice > - Information (metadata) to help in making the choice could be > added to the CDL as mark up > - CDDLM implementations have walked the tree fairly far down (to > the hardware) for deployment > - CDL may be sufficient to express both deployment and > provisioning. But it is an open issue if these two activities > can, or should be unified in this way in OGSA. In particular CDL > may not be going to the full extent of supporting costing, etc., > that maybe needed to address all requirements > - Resources beneath the cut point can be considered as > pre-provisioned: they either exist or they don't. They are not > going to be deployed themselves; but they can be used to > deploy on. > - Which resource to choose for deployment? It is the choice of > the EMS architecture (EPS, CSG) and not of CDDLM. > - Discussion on how CDL may be viewed as a hierarchy of scripts; > and that one could have a history of costs associated with > each node. In other words the tree could be decorated with > other information (cost, etc, as metadata) (3) - JSDL and CDL relation and can one cover the requirements for the > other > - A JSDL submission may be associated with a deployment > description or request, and the deployment portion could be > described in CDL. [I.e., CDL could be a more specific > application > sub-type in a JSDL document.] > - JSDL is not intended to describe the configuration of the > software that will be used by the job. The aim is to describe > things at a higher level. There may be similarities between the > languages (perhaps around resource description) but it does not > mean that one language can, or should, replace the other because > they serve different purposes. > - Jay wants to pursue the issue further among a smaller group of > people. 3) OGSA F2F meeting update (30 min) Session leaders: Please provide your goals and detailed agenda. https://forge.gridforum.org/projects/ogsa-wg/document/2005Winter_F2F_survay https://forge.gridforum.org/projects/ogsa-wg/document/2006Jan-OGSA-F2F-agen… 4) Wrap up (10 min) AOB <NEXT CALL> OGSA-WG F2F Jan. 16-20. -- Hiro Kishimoto

1 0

Re:Reference testing
by Guilherme Germoglio 06 Jan '06

06 Jan '06

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

2 1

Tracking test/implmentation queries
by Steve Loughran 06 Jan '06

06 Jan '06

I am now adding issues with the spec that surface while writing tests as CDL trackers; we can use these to make sure that any ambiguities that arise during implementation/testing are kept as open issues Dejan or Stuart, can either of you two administrators create trackers for -Deployment API -Component Model -Test Harness That way we can track all issues and reassign them when needed. thanks, steve

1 0

RE: [cddlm] phone conference
by Milojicic, Dejan S (HP Labs) 04 Jan '06

04 Jan '06

Hi Steve, Yes, we do, have you not received my reminder (see attached)? Thanks, Dejan. > -----Original Message----- > From: owner-cddlm-wg(a)ggf.org [mailto:owner-cddlm-wg@ggf.org] > On Behalf Of Steve Loughran > Sent: Wednesday, January 04, 2006 2:24 AM > To: 'cddlm-wg(a)ggf.org' > Subject: [cddlm] phone conference > > > Am I correct in assuming that we have a phone conference today? > >

2 1

phone conference
by Steve Loughran 04 Jan '06

04 Jan '06

Am I correct in assuming that we have a phone conference today?

1 0

Reminder: Regular Meeting Tomorrow, Wednesday January 4th
by Milojicic, Dejan S (HP Labs) 04 Jan '06

04 Jan '06

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.

1 0