DMI Telcon  - 26 October 2009
=============================

Present
-------

   	Mario Antonioletti, EPCC
   	Peter Turner, University of Sydney
 	Steve Crouch, Southampton
 	Shahbaz Memon, FZJ
   	David Meredith, STFC
        Gerson Galang, VeRSI

Actions:
--------

[MAA]  Give everybody on this call author privileges once on
       Grid Forge and joined the OGSA-DMI WG.

[MAA]  Look at Shahbaz's WSRF DMI rendering.

[SM]   Find out if adding xsd:any to all complex elements would
       have a negative impact.

[DM]   Add suggested changes to the text in the functional spec.

[SC]   Make introductions to get some DMI/JSDL interaction going.

[DM]   Reply to Allen's email.

[SM]   Come up with a straw man proposal for the bulk transfer 
       operation.

DONM: 8am UK time (GMT) 23rd of November.

---

MAA put a new version of the extensions on document. Very minor
changes to this version though.

DM updated the content on the DTS wiki:

http://code.google.com/p/dtsproject/wiki/DMI_JSDL_Issues

Have not migrated to Grid Forge for the time being as 
Grid Forge has been unstable. For the time being will
continue working on this platform - Dave will give 
access to folks to be able to make edits on the wiki.
DM will have more time to DMI based work in December.
Will be busy up to that point.

SC gave a heads up about a PGI WG telcon for JSDL.
They are thinking of moving credentials into the
messages for JSDL2 and BES2. For now Morris will
try to specify this in a profile which will act
as input for JSDL2.

SM thought it might be a good idea to make a composite
profile for DMI and JSDL to try and bring the two groups
closer together. 

Discussed email sent out by SM:

http://www.ogf.org/pipermail/ogsa-dmi-wg/2009-October/000512.html

- JSDL src & target & transfer requirements

File staging example. JSDL xsd:any can be used to embed transfer
requirements. Present in only one. Could be made mandatory.

- Resource identification. 

Job resource key for a single identifier for a bulk transfer
operation. Embed multiple jobs in the request.

MA noted that we still need to determine what the scope for
the work that is going to be done is going to be. What the
granularity of the control of the individual transfers is 
going to be. Seems to be that we shall try to see if we can
work at the finest level of granularity and then see how 
far that takes us.

There was a discussion about how to identify the sub-transfers.
DM keen on having a system like:

  job_id:sub_job_id

where the sub_job_id can be specified by the client to have
a meaningful name. SM not keen on doing this - the server 
should specify the sub_job_id. MA suggested using aliasing.
DM thought that the Schema could be used to specify that
the sub_job_id was unique - which had been SM's concern.

- Monitoring and Control of transfers

SM thinks we can remove a port type for data transfers and change
the status methods - possibly only have one operation and parameterise
the inputs to specify the change of state. In PGI they moved the 
control management to the factory. DM would be happy with this 
approach as it would make it easier to have a RESTful approach

SM is going to come up with a straw man proposal using pseudo schema
which he's going to send to the mailing list for discussion.

DONM: 8am UK time (GMT) 23rd of November.