August 2007 - ogsa-dmi-wg

Re: [ogsa-dmi-wg] [ogsa-wg] OGSA/OGF URI for non-bound or non-functional EPRs
by Dave Berry 31 Aug '07

31 Aug '07

In ther OGSA Data Architecture document we suggest that URI's are needed to name transport protocols, access interfaces, and query languages. I would be surprised if this list were exhaustive. ByteIO, of course, have made a start on naming SOAP transport protocols (SwA, MTOM and DIME). Dave. -----Original Message----- From: ogsa-wg-bounces(a)ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Andre Merzky Sent: 30 August 2007 12:01 To: Michel Drescher Cc: OGSA-DMI ML; OGSA-WG Subject: Re: [ogsa-wg] OGSA/OGF URI for non-bound or non-functional EPRs Hi Michel, Quoting [Michel Drescher] (Aug 30 2007): > > Folks, > > - apologies for cross-posting - > > [...] > > Also, while we were discussing this matter on the last DMI call, we > came up with the idea whether it is feasible to pull together a couple > of interested people and create an OGF Community Practice document > that may be based on > GFD.84: "Standardised Namespaces for XML infosets in OGF" > (http://www.ogf.org/documents/GFD.84.pdf) and defines, at an OGF level, > standardized URIs for things such as > - non-bound EPRs (as discussed) > - Data transport protocol identifies (GridFTP, HTTP, FTP, SRB, RFT, ...) > - ... > > Any ideas or comments? The SAGA groups would happily consume such a document - at the moment, we leave all these specification to either the implementors or (worse) to the end users, and are not satisfied with that solution. Cheers, Andre. > Cheers, > Michel -- "XML is like violence: if it does not help, use more." -- ogsa-wg mailing list ogsa-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg

1 0

OGSA/OGF URI for non-bound or non-functional EPRs
by Michel Drescher 30 Aug '07

30 Aug '07

Folks, - apologies for cross-posting - at the last OGSA-F2F, and during the follow-up weeks in the DMI WG we agreed upon and worked on a common URI for the wsa:Address field of an EPR that is either a) unbound to a service (late binding, from GenesisII @ UVa), or b) non-functional at all and merely meant as a container (OGSA-DMI 1.0) Attached is the latest draft of the OGSA-DMI specification containing the first attempt to standardize that URI. I would like to draw your attention to section 4.2.2.2 (page 10 ff.) and in particular to the description of "/dmi:DataEPR/wsa:Address". We would like to invite you to make comments on that section, and actually on the specification at large. Also, while we were discussing this matter on the last DMI call, we came up with the idea whether it is feasible to pull together a couple of interested people and create an OGF Community Practice document that may be based on GFD.84: "Standardised Namespaces for XML infosets in OGF" (http://www.ogf.org/documents/GFD.84.pdf) and defines, at an OGF level, standardized URIs for things such as - non-bound EPRs (as discussed) - Data transport protocol identifies (GridFTP, HTTP, FTP, SRB, RFT, ...) - ... Any ideas or comments? Cheers, Michel

1 0

Telcon Minutes
by Mario Antonioletti 29 Aug '07

29 Aug '07

Let me know if there are any corrections: OGSA DMI - Telcon 29/08/07 ========================== Present: Mario Antonioletti (MAA), EPCC Michel Drescher (MD), Fujitsu Steven Newhouse (SN), Microsoft Actions: [SN] Comes up with faults for the operations: Start, Activate, Stop, Restart, Suspend. [SN] Define generic/specific operations that returns all the properties for the DTI and the DTF instances. MAA was surprised to see that SN already informed the area chairs that MAA was now a co-chair. MAA did not realize this and did not send out an agenda for the telcon. MD talks through the changes made in the DMI spec (version 30). All previous changes accepted. 4.1.1 - should we define protocols in the OGSA namespace or the DMI. Comment in 4.2.2.2.1 discuss the address with the Genesis II people. There is need for a set of tokens to be defined to provide semantical information for services, e.g. protocols, formats, etc. Should possibly think about writing a community document that build on the name space document that can be extended to do this. This need has been expressed by various other groups, e.g. OGSA Data, DAIS, ByteIO. For later though. SN would rather have PersonalizedEPRs as non-normative text on p11 as it is not enforceable. SN suggests that the service should possibly sign PersonalizedEPR so that it cannot be re-used by others. DM wrote something along those lines later on. DN is in agreement with this and this will text be moved/changed. PersonalizedEPR goes into the security section. A number of other small changes on p11 are discussed and approved. Contradictory statement on p12 noted. The MUST should be changed to a MAY. Changes on p13 reflect discussion on the mailing list. It seems to be ok. Comment on security credential. DM would be happier if that was moved into DMI profiles. SN thinks it should go to the security section where it will state that these mechanisms will defined in DMI profile. Transfer requirements - got rid of the comment on the timing, semantics described later. Section 4.3 faults - replaced the text. Deleted the credentials failed fault as this only happens when you try and move the data - not at the factory. On p18 have put comments on the operations and was wondering whether we should define faults. SN thinks we should and has been actioned. We want to have alternative renderings of DMI - WS-I/WSRF - but WSRF restricts how faults should be implemented, it defines specific faults for its operations but it is silent on how operations not using WSRF implement faults - so you don't have to use these. You may use WSRF. However, have two renderings but for interoperability the shared operations must not be derived from the WSRF faults. We need to define operations that are shared between the two renderings. A lot of discussion has gone in BES on this topic, hence SN actioned. Section 5.3 will be populated with Steven's suggestion. 5.4.1.5 not clear on the sub-states on the syntax of how these are specified. SN thinks this should be attributes. Section 6 is more or less unchanged. The Glossary section has been deleted. Quickly run over the email exchanges on the mailing list. Most of them had already been discussed on the call. Discussion as to how far we are in the process of producing a spec. Need to socialise the spec to get comment on the spec (comments from Ravi). MD can now publish some draft WSDL. DM will make the changes from the call and then SN will take the pen. Once the WSDL is done can start some early implementations. +-----------------------------------------------------------------------+ |Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ. | |Tel:0131 650 5141|mario@epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ | +-----------------------------------------------------------------------+

1 0

New spec version online
by Michel Drescher 29 Aug '07

29 Aug '07

Folks, I uploaded a new version of the spec reflecting the discussions on today's conf call. I took the liberty to sort the authors in the page header in ascending order relative to the last names of the authors. Please download the new version from http://forge.ogf.org/short/ogsa-dmi-wg/spec. Cheers, Michel

1 0

Telecon - 29th August 2007
by Steven Newhouse 28 Aug '07

28 Aug '07

When: 9am (Pacific), 11am (Central), 5pm (UK) PIN: 2719140 USA: +1 866 500 6738 (Toll: +1-203-480-8000) UK: +44 118 909 2000 Could one of the chairs (note the updated web page - http://forge.gridforum.org/sf/projects/ogsa-dmi-wg) please provide an agenda? Steven

2 1

Minutes
by Ravi Madduri 24 Aug '07

24 Aug '07

All: Please find attached minutes I took during the call. Please review them and let me know if I missed anything Thanks -- -- Ravi Ravi K Madduri The Globus Alliance | Argonne National Laboratory http://www-unix.mcs.anl.gov/~madduri

3 2

New version
by Steven Newhouse 23 Aug '07

23 Aug '07

https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-dmi… Revised following today's call. I would suggest reading a version without showing markup... but one of the diagrams disappears! Steven

2 3

Alternative Rendering of the Functional Specification
by Michel Drescher 23 Aug '07

23 Aug '07

Folks, I have been digging into the problem of alternative renderings for OGSA-DMI. As per charter we are supposed to deliver at least two different renderings: a) WS-I BaseProfile compliant rendering b) WSRF compliant rendering. Leaving the additional WSRF operations out of the equation for the moment there is indeed a terminal incompatibility between those two renderings. I am not sure about the WS-I part on this picture, but the WSRF part of that picture is as follows, particularly the WSRF BaseFault specification (WS-BaseFaults v1.2). Chapter 3 in the BaseFaults specification defines how BaseFaults (and derived distinguieshed types) MUST be used in WSDL 1.1. Lines 237 to 239 of that specification explicitly links a BaseFault or any of its derived types through a (WS-I compliant!) wsdl:message to a wsdl:operation declaration. In other words, this is a closed link that leaves no room for alternatives. Hence alternative renderings MAY be interoperable on the input and output messages of any genuinely defined operation (such as the DTF's "requestDataTransfer()") but when it comes to faults alternative renderings CANNOT be interoperable as there MUST be a distinctively defined fault element present. I believe that WS-I has similar if not the same requirements. Any expert around here? Having said that I believe that alternative implementations of different renderings will not be interoperable, unless we define interoperability to exclude any fault messages. We might, if we define common wsa:Action values and explicitly allow a CONSUMER (from WS-I Basic Profile 1.1) to ignore the soap:Fault child element. Comments? Cheers, Michel

1 0

New document & telecon
by Steven Newhouse 21 Aug '07

21 Aug '07

*** NOTE TIMES *** Date: 22nd August 2007 When: 9am (Pacific), 11am (Central), 5pm (UK) PIN: 2719140 USA: +1 866 500 6738 (Toll: +1-203-480-8000) UK: +44 118 909 2000 Agenda: 1. IPR Notice 2. Agenda Bashing 3. Minutes of the last meeting http://forge.ogf.org/sf/docman/do/downloadDocument/projects.ogsa-dmi-wg/doc… 4. Brief Action Item review http://forge.ogf.org/sf/tracker/do/listArtifacts/projects.ogsa-dmi-wg/track… 5. Current Document Review http://forge.ogf.org/sf/docman/do/downloadDocument/projects.ogsa-dmi-wg/doc… Review state diagram Review security changes (see for example - http://forge.ogf.org/sf/docman/do/downloadDocument/projects.ogsa-dmi-wg/doc… - top of page 2) 6. Review Actions for next meeting 7. AoB

1 0

***SPAM*** Current Version
by Steven Newhouse 16 Aug '07

16 Aug '07

All, While presenting the current gridforge draft (v26) both Michel and I realized that the current version was missing edits that we had agreed on the last telecon. Michel will do updates on Thursday and I will do work on Friday to clarify issues raised today at the OGSA F2F. Please do not start reading the draft just yet. Steven

1 0