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

CDDLM/ACS joint session
by Keisuke Fukui 24 Jun '05

24 Jun '05

Folks in the CDDLM-WG, This is for you to confirm time and place for our joint session. ------------------------------------------------------------------------ Jun 28 2:30 p.m. - 4 p.m. Application Contents Service - WG #1 Calendar: Michigan Details: Discussing interface between CDDLM and ACS. ------------------------------------------------------------------------ We will start the sequence diagram for the possible interaction between CDDLM and ACS, which we've started discussion on cddlm-wg ml. Then, we would like to cover possibilities beyond that. Please be sure be there. We are looking forward to see you all. -Keisuke Fukui

1 0

RE: [cddlm] Component Model Last Call
by Milojicic, Dejan S 24 Jun '05

24 Jun '05

Hi Team, We would like to submit component model spec prior to GGF. If there are any concerns and comments, this will be the last moment to raise them. We plan to submit the spec later today or over the weekend. Similar applies to Deployment APIs, except that we may do it while at GGF. Both specs were out for a while, so there should not be surprises. Thanks, Dejan. ________________________________ From: owner-cddlm-wg(a)ggf.org [mailto:owner-cddlm-wg@ggf.org] On Behalf Of Stuart Schaefer Sent: Monday, June 20, 2005 10:32 AM To: cddlm-wg(a)ggf.org Subject: [cddlm] Component Model Last Call Attached is the final draft of the CDDLM Component Model. This will be the Last Call for comments on this version of the specification. The document includes fixes for the events declared by the component model, causing XML validation errors. There is a new section clarifying the effect of scope on control flow operations, to ensure that spaghetti control flow does not occur. I have a proposal on how to address Jun's comments on component model element inheritance. It is not included in this draft. I will send it in a separate email, for discussion on Wednesday. Please take time to review this document. Any and all comments are welcome. Stuart

2 1

CDL: question about attributes and namespaces
by Steve Loughran 24 Jun '05

24 Jun '05

Imagine I have a base declaration of a component, say <cmp:OnFault cdl:extends="cmp:Notification" faultName="" faultType="" /> now, imagine I extend that in a new namespace Should I put the attributes in the namespace of the component I extend <tns:MyFault cdl:extends="cmp:OnFault" cmp:faultName="DeploymentFault" /> Or can they be left as is: <tns:MyFault cdl:extends="cmp:OnFault" faultName="DeploymentFault" /> That is, when we merge attributes, do we use the full QName, or just the localname. I know it would appear to make sense to use the full qname, but the trend to use unqualified attributes may cause confusion here. I know my parser already warns whenever it hits an unqualified extends="" attr, as that is often a result of me forgetting that namespace.... -steve

1 0

FW: WSDM-related sessions in GGF14
by Milojicic, Dejan S 23 Jun '05

23 Jun '05

-----Original Message----- From: Fred Maciel [mailto:Fred.Maciel@hds.com] Sent: Thursday, June 23, 2005 3:25 PM To: Milojicic, Dejan S Subject: WSDM-related sessions in GGF14 Dear Dejan, Here are the WSDM-related sessions in GGF14 on the 29th (Wednesday). Could you please forward it to the CDDLM mailing list? (1) 9 AM - 10:30 AM, Wellington 2 room: WSDM Deep Dive (booked as "OGSA-WG session #8") Detailed explanation of the WSDM specs to the GGF, with discussion. (10:30 AM - 11 AM: coffee break) (2) 11 AM - 12:30 PM, Consulate 1&2 rooms: WSDM-OGSA-CDDLM joint session (booked as "OGSA-WG session #9") That's the joint meeting among the CDDLM-WG, the WSDM TC and the OGSA-WG. The agenda is not fixed yet, so here goes a proposal: - Outline of the status on all three WGs (including an explanation of what "OGSA base profile" means). - Explanation and review of how the CDDLM-WG applied WSDM to their specs - A discussion on how we need to work to apply WSDM to the OGSA specs (given that work on "concrete" OGSA specs has started, now is the right timing). If we have more to discuss with the CDDLM-WG specifically, we might use part of your 6:00 PM - 7:30 PM session. (12:30 PM - 2 PM: All-GGF Town Hall lunch meeting) (3) 2 PM - 3:30 PM, Governor's Suite: Multi-vendor WSDM demo Given that there is a CDDLM-WG session and an OGSA-WG-related session in parallel with the demo (it was impossible to avoid clashes) I'm thinking about us giving a mini-demo right before 2 PM to the OGSA-WG and CDDLM-WG participants. See you there, Fred Maciel Hitachi America R&D

1 0

Change in my version of the deployment-api.wsdl
by Ayla Debora Dantas de Souza - Projeto Ourgrid 23 Jun '05

23 Jun '05

Hello, another necessary change in order to make the deployment-api.wsdl work with Muse was the definition of the "<wsdl:types>" element, and then, just inside this part I had imported the schemas. I've used the <wsdl:import> elements just to import .wsdl files. I also had to define two <wsdl:service>, one for the System, and another for the Portal. Maybe the oficial version should not reflect these changes I've made, but maybe you can like them. Ayla

2 1

Fwd: Teleconference minutes - 20 June 2005
by Hiro Kishimoto 23 Jun '05

23 Jun '05

Hi CDDLMers, Thank you very much for coming to our call. Attached is the meeting minutes. If you have any questions or comments, please let us know. Thanks again and see you in Chicago! -- Hiro Kishimoto

1 0

RE: [cddlm] XML-CDL schema issue
by Stuart Schaefer 23 Jun '05

23 Jun '05

The ##local and ##other namespaces are not mutually exclusive. They overlap. That is the root cause. I do not vote for "requiring" fixup. We should discuss this at GGF and look to solve after next week. Stuart -----Original Message----- From: Steve Loughran [mailto:steve_loughran@hpl.hp.com] Sent: Wednesday, June 22, 2005 5:20 PM Cc: cddlm-wg(a)ggf.org Subject: Re: [cddlm] XML-CDL schema issue Stuart Schaefer wrote: > Jun and Steve, > > > > Microsoft was supposed to have fixed their XML parser issues with .NET > 2.0. It appears that most issues that I have tested are resolved. > However, the issue with ##local and ##other are still there. ooh. that is not good. is it an acknowledged bug, or just a different interpretation of XSD? > The > XML-CDL schema defines the propertyListType and cdl elements to have an > unlimited choice of either element. MSXML will not accept this. We > will either need to allow for a .NET schema and Java schema or my > proposal would be to eliminate ##local and force all elements to have > namespace qualification. 1. having two different XSDs that map to the same URL is always a bit controversial; it would stop us hosting a consistent image at the end of the URL. However, the semantics of the two schemas would actually match. That is, under .net, the ##other declaration would cover local elements; under xerces the pair of ##local,##other would do what we want. it is only if the schema is used on the wrong runtime that we have a problem. 2. I already do fixup in the build (target "patch-api") to swap between local versions of the schemas and the normative remote locations. Adding some more copy/patch work is not hard at all. 3. I (currently) quite like local stuff, and have used it a lot in my tests. changing it now would break my tests, and this week is a bad week do to that. The week after GGF would work better. 4. I think I need to fully understand the interaction between XSD namespaces and <import> namespaces. They are essentially orthogonal, arent they. <import> namespace just provides a namespace for something to import into, the contents of <cdl:configuration> dont need to be in that NS, we just somehow isolate all toplevel propertylist elements by that namespace. Except, I already isolate stuff by a namespace if you give an element one. --------- Overall, I am mostly in favour of keeping ##local stuff and doing fixup. But because of my confusion about (4), i worry that there is something I dont understand there, and everything ought to be in a namespace. Specifically, if you want to be able to import other people's documents, to extend them, you may need everything in a namespace. -steve

1 0

Question on cdl:types
by Stuart Schaefer 23 Jun '05

23 Jun '05

In implementing cdl:types, I have run into a few questions: To define types, you need to do what the full-example-1.cdl document taken from the CDL spec does. <cdl:types> <xsd:schema> ...... </xsd:schema> </cdl:types> But, if we allow any random XML from any namespace in there as the CDL schema does, then I have to go sorting around dumping what is uninteresting, and finding if there is really any schema to be had. I know it is valid, it is just a lot of extra work. There is also a problem with defining multiple schemas within the cdl:types element. In order to support multiple schemas, the cdl:cdl/@targetNamespace attribute has to be multivalued or multiply defined. Is this the expectation? It is really easy to change <cdl:types>? <cdl:documentation .../>? <-- schema definition -->* <-- extensibility element -->* </cdl:types> to <cdl:types>? <-- schema definition --> </cdl:types> In this way, there is one local schema and one targetNamespace attribute. Also, what is the "extensibility element"? Stuart

1 0

GGF14 edition of the deployment
by Steve Loughran 23 Jun '05

23 Jun '05

when I get back from GGF, I am going to roll back all copies of office2003 to office XP, in the hope they handle pictures better. That is all I will say on the subject. This is the draft for GGF14 of the deployment api; please review and correct where appropriate. -steve

2 1

RE: [cddlm] In preparation for the CDDLM/ACS joint session at GGF14
by Milojicic, Dejan S 22 Jun '05

22 Jun '05

Hi, We can also start this discussion at our last regular CDDLM phone conference before GGF, which will start in about half an hour. Thanks, Dejan. > -----Original Message----- > From: owner-cddlm-wg(a)ggf.org [mailto:owner-cddlm-wg@ggf.org] > On Behalf Of Steve Loughran > Sent: Wednesday, June 22, 2005 4:47 AM > To: Keisuke Fukui > Cc: 'cddlm-wg(a)ggf.org' > Subject: Re: [cddlm] In preparation for the CDDLM/ACS joint > session at GGF14 > > Keisuke Fukui wrote: > > Folks in the cddlm-wg, > > > > As you know we will have a joint session at GGF14 between > CDDLM and ACS. > > This is in preparation for the session from acs-wg. > > After the GGF13 inside the acs-wg, we studied and discussed > about the > > possible interactions between CDDLM and ACS, especially in terms of > > "File upload" section and AddFile() in the deployment API document. > > Sequence diagrams in the attachment describe our > interpretation about > > how CDDLM works, and our proposal for the possible > interactions in the > > case that the ACS co-exists in the system. We believe our proposal > > goes along with what the current set of CDDLM specifications define > > and doesn't require change in the original definitions. > > > > We are looking forward to discuss about this at the joint > session for > > CDDLM/ACS at GGF14. It is very much appreciated if we get responses > > before the joint session at GGF14 in case that important > overlook in > > our understanding is found. Please feel free to make > comments or questions. > > > > FYI, > > At GGF14 joint session, we'd like to start our discussion with this > > diagram and if we don't find critical issues, we may go down to the > > detail of the interface and/or advanced interaction. We'd > also like to > > hear requirements on ACS in terms of the event notification and > > asynchronous invocation of the interfaces, if the time permitting. > > > > Thanks in advance for you efforts on this! > > > > Best Regards, > > Keisuke Fukui > > ACS-WG > > > > thank you, I will comment briefly. > > -The File upload stuff was very much written to be a > transient/interim solution in the absence of a real > repository, which is why it is so minimal and barely > functional. I didnt want to be dependent upon anything not > yet designed, but didn't want to do a repository myself > > -the current revision allows the sender to declare the URL > schema to use. That could be file: for a shared filesystem > and http: or https for HTTP access. It could also be fancy > custom stuff; there is some java project whose name escapes > me that provides a multicast URL resolution system, the file > could be stored across multiple machines without ever having > to give them a hostname, which is very good for fault-tolerance. > > -There is also support for adding metadata to a request, but > nothing to do searches, retrieval, or even introspection on > what stuff is supported. I've left that for implementations. > > -There is the perennial problem of how to get files up over > SOAP. SwA is only available in java distrubutions, and then > not consistently, DIME is in .NET WSE and Axis 1,x, but even > more unpopular. As for MTOM, well, who implements that yet? > > As a workaround I've put in stuff for having the endpoint > actually retrieve the files themselves, but this is a bit > unsatisfactory, because it requires the files to be broadly > visible on the 'net, and introduces race conditions. > Otherwise, data goes inline in base-64 encoded form, > unless/until MTOM lets you pretend that the file attached to > the message is really inline base 64. > > > here are two example mesages and responses from the > XSD-validation tests > > > > <api:addFileRequest> > <api:name>urn://45</api:name> > <api:mimetype>application/x-pdf</api:mimetype> > <api:schema>file</api:schema> > <api:uri>http://example.org/files/source.pdf</api:uri> > </api:addFileRequest> > </t:test> > > <api:addFileResponse> > <item>file://nas1/temp/source.pdf</item> > <item>file://nas2/4fgdbb.tmp</item> > </api:addFileResponse> > > > > <api:addFileRequest> > <api:name>urn://46</api:name> > <api:mimetype>application/x-ssh-key</api:mimetype> > <api:schema>http</api:schema> > <api:data> > AAAAB3NzaC1yc2EAAAABIwAAAIEAwVmUkPzXdWEyJZ8nCR8GvdrDtO00RI4Z > Bg3Gyviuz5IrWj2C6b2BdcKn+S/swDV1fiEFY4+ewYHUfmg+UKm2T8Lfksjn > Hinks0GoVvkwy3bF48U5yVk1akAzR5YbSLJa6Naj8XS9681xVzWpbjxrV3KR > QNWvEqI0MqRE34MzT4M= > </api:data> > <api:metadata> > <x:expires date="2005-07-18" > xmlns:x="http://example.org/expiry" /> > </api:metadata> > </api:addFileRequest> > <api:addFileResponse> > <item>http://server/job5/files/1</item> > </api:addFileResponse> > > > On a related note, I see that Fujitsu are listed as one of > the interested parties in JSR 277, the java > modules/repository proposal. Are you involved in that? > > -steve > >

2 2