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@stfc.ac.uk tel: +44 (0) 1925 603762 -- Scanned by iCritical.
Hi Dave, As discussed by Skype, down here we're inclined to the use of DEPRS and the use of element references for flexibility and convenience. Cheers, Gerson david.meredith@stfc.ac.uk wrote:
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/... ), 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@stfc.ac.uk
tel: +44 (0) 1925 603762
-- Scanned by iCritical.
------------------------------------------------------------------------
-- ogsa-dmi-wg mailing list ogsa-dmi-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-dmi-wg
participants (2)
-
david.meredith＠stfc.ac.uk -
Gerson Galang