ogsa-dmi-wg

Download

ogsa-dmi-wg@lists.ogf.org

March 2010

5 participants
12 discussions

Re: [ogsa-dmi-wg] Resigning my chair.
by Mario Antonioletti 09 Mar '10

09 Mar '10

Hi, > I understand. Thanks for your excellent work and enthusiasm. I hope you can > still be involved with OGF. I am happy that Steven Crouch has agreed to > continue your good work. I see that you copied the OGSA-DMI mailing list. > As long as there is consensus on the list, we can approve the smooth > transition. Thanks David. No one in the list has objected so I take it that there is consensus. We will make the transition at OGF28. Mario +-----------------------------------------------------------------------+ |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/ | +-----------------------------------------------------------------------+ -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

bulk copy strawman proposal
by david.meredith＠stfc.ac.uk 05 Mar '10

05 Mar '10

Hi folks, (To address my actions from the last DMI phone conf): As you are aware, I have been given the task to come up with a straw-man proposal for a 'bulk' data copy activity document prior to OGF that may/may not build upon on the DMI functional spec (for the purpose of describing multiple data copy operations across different sources and sinks). I would appreciate your views/preferences on the following salient points before I start this task (I also emailed Andreas and Donal from JSDL to canvas their opinions also - awaiting a reply). Anyhow, I guess the salient points as discussed in the paper that need an early decision are listed below (note, if you would like a copy of the cited paper please email me directly, I'll send you a copy since its awaiting final publication review): 1) The preferred format to pursue to describe the data source and sink? i.e. a) the jsdl inspired <mjsdl:DataTransfer/> element with nested <mjsdl:Source/> and <mjsdl:Target> elements (http://code.google.com/p/dtsproject/source/browse/trunk/dts-schema/src/ main/resources/minx-jsdl-example.xml ), or b) the DMI inspired <DataCopy/> element based on DEPRs as shown in Fig 4 in the paper. 2) Should we pursue the use of element references as discussed in Figure 5 in the paper to reduce XML repetition (i.e. support references in addition to the traditional in-line approach)? Potential referenced elements include; <Source/>, <Target /> (assuming option 1a), <DataERP/> (assuming option 1b), <TransferRequirement/>, <URIProperties/> and <Credentials/>. Some considerations: If option 1a) is preferred, do we further extend this so that it can be used to reference multiple alternative source/sink data locations akin to the dmi DEPR construct, i.e. allow multiple <mjsdl:Source/> and/or <mjsdl:Target/> data locations within a single <mjsdl:DataTransfer/>. In doing this, we actually define a construct very similar to the DEPR construct. Many thanks, Dave ---------------------------------------------- David Meredith STFC eScience Centre Daresbury Laboratory (A32) Warrington, Cheshire WA4 4AD email: david.meredith(a)stfc.ac.uk tel: +44 (0) 1925 603762 -- Scanned by iCritical.

2 1