June 2005 - cddlm-wg - lists.ogf.org

CDL and namespaces
by Steve Loughran 15 Jun '05

15 Jun '05

As implement extends, I find tests failing and have to decide if they are real failures or not. Here is my current one. <?xml version="1.0"?> <cdl:cdl xmlns:cdl="http://www.gridforum.org/namespaces/2005/02/cddlm/CDL-1.0" xmlns="http://example.org/webapps" > <cdl:configuration> <server> <port>8080</port> <security>true</security> <webapps/> </server> </cdl:configuration> <cdl:system> <tomcat cdl:extends="server"> <basedir> </basedir> </tomcat> </cdl:system> </cdl:cdl> This file fails to resolve extends="server" because the xmlns="http://example.org/webapps" declaration puts the server declaration into that ns. My extends lookup logic assumes that any localname without a namespace is in the empty namepace. Question is, is that the right assumption? The other, perfectly valid one, would be to say that any localname in an extends declaration is in the same namespace as the element that is being extended. To get something in the empty namespace, I'd have to say extends=":something". I dont see anything in the spec which covers this issue, so will file this as an issue on ggf.org. -steve

1 0

more on namespace resolution
by Steve Loughran 15 Jun '05

15 Jun '05

OK, I have one more test that is unhappy with the quirks of namespaces, and don't know the implications of. it is essentially: "how does targetNamespace interact with default namespaces of things". If I have a CDL file which declares a target namespace, are all components installed into that namespace for reference by other things, including the components themselves? that is: does this document resolve the extension properly, or does it fail with an unknown element error: <?xml version="1.0"?> <cdl:cdl xmlns:cdl="http://www.gridforum.org/namespaces/2005/02/cddlm/CDL-1.0" targetNamespace="nap://velvet+underground/european+sun" xmlns:tns="nap://velvet+underground/european+sun"> <cdl:system> <Component /> <Extension cdl:extends="tns:Component"/> </cdl:system> </cdl:cdl> -steve ps. the nap: url schema was a relic of napster; each one searched for content under that name. I use it for unique names, but also to verify that whatever holds the URIs is not enforcing them to be resolvable URLs.

1 0

Notes and interop
by Milojicic, Dejan S 15 Jun '05

15 Jun '05

Hi, These are quick notes from the meeting that took place on 6/15. Ayla, Stuart, Steve, and Dejan attended. We discussed issues with WSDM compatibility, some issues that Ayla raised have been addressed by Stuart, some others will be dealt with between Steve and Ayla. Stuart will post the document for the last call later tonight, which will enable us to send it to editor prior to GGF. Steve will do the same with the deployment API, which will enable us to have all documents submitted prior to GGF, quite an accomplishment. We are still shooting to demo some limited functionality of all CDDLM main components, but this is still "game-time" decision by each owner. I am not sure if I posted the interop specs to the whole CDDLM list or only to individual owners, so I am reposting them to the whole mailing list this time. By the way I have seen both use cases last night at International Conference on Autonomous Computing, and they went really fine. This sort of use case/scenario is something we need to develop prior to the GGF in Fall or wherever we will have decided to demonstrate interop. We will have our regular meeting next Wednesday, which is the last one before GGF. Thanks, Dejan. -----Original Message----- From: Murray, Bryan P. Sent: Friday, June 03, 2005 7:58 AM To: Milojicic, Dejan S Subject: Dejan, I am including the interop scenarios from both WSDM and WSRF. Bryan

1 0

updated deployment API
by Steve Loughran 14 Jun '05

14 Jun '05

Hello, this is the final pre-GGF14 update. 1. the .doc file shows the most recent changes 2. the .pdf is the one for broad circulation. Dejan, shall I put this + the WSDL/XSD up on the documents list on the site?

1 0

import namespaces
by Steve Loughran 13 Jun '05

13 Jun '05

I have a question for Jun regarding namespaces and import Imagine a CDL document which declares a target namespace <cdl:cdl cdl:targetnamespace="http://123" />...</cdl:cdl> Now import that document. Which of the following import statements are valid? (a) same namespace as before <cdl:import namespace="http://123" location="http://example.org/ex/cdl" /> (b) different namespace <cdl:import namespace="http://456" location="http://example.org/ex/cdl" /> (c) no namespace <cdl:import location="http://example.org/ex/cdl" /> Unless told otherwise, I would assume that only option (a) is valid, (b) and (c) are errors. (b) is an obvious discrepancy, though (c) could almost be handled, with the right policy "give everything in the imported doc its targeted namespace". -steve

1 0

CDL: scope of names
by Steve Loughran 10 Jun '05

10 Jun '05

I just want to make sure that I am writing the correct tests here, and want to ask some questions about resolution Is it true that 1. you cannot have the same name in cdl:configuration, cdl:system and anything we imported without giving a namespace 2. when we resolve things, you can have a forward reference from cdl:configuration to cdl:system 3. you should use a prefixed reference to resolve to a name in a different namespace. I am also confused about the implications of #3. -should the default namespace be (a) something you specify with cdl:targetNamespace on the <cdl> document (b) what you declare with any schema declarations. Answers welcome. Oh, how I despise XML namespaces. -steve

1 0

Component Model discussion points
by Stuart Schaefer 10 Jun '05

10 Jun '05

Over the past week, several questions were asked about the Component Model. They will be documented here and my response summarized for the team and any further questions on how to resolve them. 1) Component Model tags as elements or attributes - how to resolve inheritance issues Using the CM definition of tags for elements such as <cmp:delegate> or control flow elements, there is the possibility for complex behavior. A control flow element such as <cmp:sequence> can be multiply defined. As CDL elements are property lists, it is unclear whether multiply defined elements are allowed. XML allows such behavior and the CDL specification does not explicitly prevent it. There can be three possible types of behavior of inheritance when multiple properties of the same name are specified in a single list. (1) disallow multiple occurence. (2) batch override (3) streaming override The CDL specification defines inheritance as a batch override process where the nodes of a new list will overwrite the nodes of the original list. This is the only behavior that is feasible. It was thought that by defining the CM elements as attributes, this problem would be solved. That is not the case, as CDL defines a similar override process for attribute inheritance. 2) Delegate and inheritance's impact thereon The current definition of the <cmp:delegate> element does not allow any process of inheritance to change the delegation behavior of a node. If a node is a delegate, it cannot be "turned off" through any means. It was posited that allowing a Boolean value for the delegate element would allow delegation to be turned on and off. >From an inheritance perspective, I am concerned that people would attempt to "turn on" or "turn off" delegation. This would require that all components be made to support both compound and primitive operations (in SmartFrog speak). Otherwise, we can "RECOMMEND" the use of the value, such that implementers not "turn on" delegation unless they know that a component supports such methods. In our weekly meeting we proposed to leave the current behavior as it stands, and discuss this topic for potential change in the next version of the specification. We will solicit usage cases for this behavior. 3) CMP switch element Concern was expressed regarding the value of the <cmp:switch> element and its potential for creating spaghetti control flow. If flow control is allowed to arbitrarily violate scopes of control flow, then undetermined behavior will result. I will be updating the component model to clarify the scoping behavior of control flow elements to describe how this is not the case. This does not change the concern over the utility of the element. It may be complex to implement, with unknown value. 4) Event sequencing There is concern that event registration is only done at the producer side of the event model. The consumer or target of the event cannot register for the event. I believe that this is merely a situation of the semantics of the CDL element chosen to represent events. Rather than declaring a component can send events, and that another component will register for that event, the CM defines in one construct this process in addition to ordering restricition semantics. The current definition sacrifices completeness for compactness and simplicity. The primary issue is resolution of synchronization conditions at the consumer side. It is possible that a consumer of an event is within some scope of control flow, thus must ensure that it both obeys control flow and the semantic of the event. There is also concern of inheriting these event registrations, though it is unknown what effect this will have.

3 4

Notes from the CDDLM meeting, 6/8
by Milojicic, Dejan S 08 Jun '05

08 Jun '05

Attendees: Ayla Debora Dantas de Souza, Kojo Takashi, Jun Tatemura, Steve Loughran, Stuart Schaefer, Jun Tatemura, and Dejan Milojicic. Agenda: 1. Feedback on Component Model spec 2. Brief look at the Deployment API and CDL 3. Quick look at what will happen at GGF 1. A lot of good discussions. Some of the topics included: - Complex nature of inheritance (tags for sequence and reverse create complication how attributes and elements get inherited) - Ensuring that the markers in CDL are used as attributes not as elements - Delegates and inheritance's impact thereon - CMP switch element - Event sequencing Stuart will summarize and post it to CDDLM mailing list and possibly even put a separate document into the GridForge. We will not include these in the current component model spec. At the moment we are close to an agreement on all issues, Jun will rethink it and confirm one or the other way. 2. Steve will apply changes suggested by Ayla and Stuart and put up the document for the last call. 3. We will have the following activities at GGF - CDDLM session on all documents (largely Q&A) - CDDLM session on demos (Jun, Stuart, and Steve will give the demos of their work) - CDDLM session on Reference implementations - CDDLM session on Interop - CDDLM session on WSDM and CDDLM - CDDLM session on CDDLM and other SRM groups (JSDL, GRAAP, DRMAA, ACS, etc. invited) - ACS session on ACS and CDDLM - OGSA session that CDDLM will attend and discuss relationship between the two (which session, TBD at the June 20 OGSA phone conference that CDDLM will attend).

1 0

CDL test files
by Steve Loughran 08 Jun '05

08 Jun '05

I am seeking as many possible CDL test files to put into the set of test files I'm building up on sourceforge. Categories wanted -files that test the XSD matches what we expect. -files that are valid syntax, but invalid semantics - references that dont resolve - duplicate names - any other error documents -files that are valid. Particular those with early/late references, and what they should resolve to. I have all the examples of the CDL spec pasted in, but I want more examples to test references and expressions. What test files are the other implementors using? -steve

1 0

FW: [sched-chairs] NOTES: GGF SRM Area - Chairs Telecon, 7 Jun 2005
by Milojicic, Dejan S 07 Jun '05

07 Jun '05

Hi, The CDDLM meeting is tomrorow as usual, at 6am PST. Thanks, Dejan. -----Original Message----- From: owner-sched-chairs(a)ggf.org [mailto:owner-sched-chairs@ggf.org] On Behalf Of Bill Nitzberg Sent: Tuesday, June 07, 2005 8:14 AM To: sched-chairs(a)ggf.org Subject: [sched-chairs] NOTES: GGF SRM Area - Chairs Telecon, 7 Jun 2005 GGF Sched Area - Chairs Telecon Notes, 7 Jun 2005 ================================================== Attendees (with '*'s): ---------------------- *Bill Nitzberg, Area Director +Stephen Pickles, Area Director Keisuke Fukui, ACS-WG Thomas Studwell, ACS-WG Peter Ziu, ACS-WG *Hrabri Rajic, DRMAA-WG Andreas Haas, DRMAA-WG Wolfgang Ziegler, GRAAP-WG Jim Pruyne, GRAAP-WG Volker Sander, GRAAP-WG Jon MacLaren, GESA-WG Steven Newhouse, GESA-WG Steven Newhouse, RUS-WG Bill Horn, RUS-WG Rebekah Metz, UR-WG Stephen McGough, JSDL-WG Ali Anjomshoaa, JSDL-WG Darren Pulsipher, JSDL-WG *Dejan Milojicic, CDDLM-WG Takashi Kojo, CDDLM-WG *Ramin Yahyapour, GSA-RG Uwe Schwiegelshohn, GSA-RG Jarek Nabrzyski, GSA-RG Ewa Deelman, WFM-RG Jim Blythe, WFM-RG Miron Livny, WRM-RG ('+' == could not attend, but emailed status report) NB: --- PLEASE ensure all sessions are scheduled for GGF14 (if you haven't already). Schedule overview: Monday, 6/27 Chair Updates: 1:30pm-2:30pm, Regent 1 New Chair Training: 2:30pm-3:30pm, Regent 1 Welcome Reception: 5:30pm-7pm, Cotillion Room Tuesday, 6/28 GGF14 Opening: 9am-10am GGF101: 10am-11:30am, Windsor Chair Appreciation: 8:30pm, location TBD Compute Area Meeting (tentative), Tue late Town Hall, 6/29 12:30pm-2pm GGF14 Closing & Summary, 6/30 1:30pm-3pm GGF15: 3- 6 Oct 2005, Boston Status ------ ACS-WG -- ** PLEASE SEND STATUS TO sched-chairs(a)ggf.org CDDLM-WG -- Pretty good shape. Very close to having all specs submitted. (Just received extensive comments.) Expect to have all specs in the Editor's hands by GGF (or slightly after). One session to discuss specs, also sessions for: demos, interop & future, WSDM, w/other SRM groups, ref. impl., joint-ACS. DRMAA-WG -- Secretary will host DRMAA session (and participate in CDDLM join session) Working on docs; target for last-call/Editor is after GGF14. GESA-WG -- (hibernating...) GRAAP-WG -- ** PLEASE SEND STATUS TO sched-chairs(a)ggf.org GSA-RG -- Working on use case doc; expect to have updated Use Case doc for GGF14. JSDL-WG -- ** PLEASE SEND STATUS TO sched-chairs(a)ggf.org RUS-WG -- ** PLEASE SEND STATUS TO sched-chairs(a)ggf.org UR-WG -- ** PLEASE SEND STATUS TO sched-chairs(a)ggf.org WFM-RG -- ** PLEASE SEND STATUS TO sched-chairs(a)ggf.org Upcoming Telecons ----------------- Every other Tuesday (skipping holiday weeks) 8a US Pacific (see www.worldtime.com to convert) Usually very short (less than 15 minutes long) Dial-in: 1-800-387-6159 & 1-303-248-0173 Conference ID: 7144404 Upcoming Telecons / or status reports due before: 21 Jun 2005 If you can't make a telecon, please send us a note. If no chairs from your group will make a telecon, please also send a status update to everyone on the list (sched-chairs(a)gridforum.org) As always, please keep things moving forward --- if you need help setting up a separate mailing list or teleconference calls for your group, etc., don't hesitate to ask us. Thanks all! - Bill & Stephen GGF SRM Area Directors

1 0