[GSM-WG] SRM (GSM) and OGF

[Flavia Donno]

I have made the same notes to Arie and Alex.
My PhD thesis + a couple of publications that we have already provide 
static and dynamic models for SRM v2.2.
The model is not complete. Therefore, we will try to address this in 
conjunction with a few researchers of the University of Geneva.

Flavia

Jensen, J (Jens) wrote:
> Hi Paul.
>
> These are very useful comments, and we would be happy to be working with
> you on improving the specification.
>
> I have now requested two 45 min sessions at the OGF where these issues
> can be discussed (the deadline is today and I didn't hear anything from
> Arie but he may be busy).  Paul if you are attending the OGF, I hope you
> will attend - if not, we can discuss issues beforehand.
>
> Many thanks,
> --jens
>
>
> Paul Millar wrote:
>   
>> Hi Jens, others in GSM and SRM-devel,
>>
>> Some comments as an interested outsider...
>>
>> On Wednesday 09 January 2008 14:11:22 Jensen, J (Jens) wrote:
>>   
>>     
>>> I would propose we start an activity to review the spec and document at
>>> least the most obvious discrepancies.
>>>
>>> The aim is partly to ensure that someone new who picks up the standard
>>> can start implementing an interoperable SRM.  Partly that we need to be
>>> responsible standards maintainers, now that SRM is an OGF standard.  Of
>>> course if there are no changes then so much the better, but it would be
>>> good to be able to say so.
>>>     
>>>       
>> The GridForge page for tracking comments could be used:
>> 	
>> http://forge.gridforum.org/sf/discussion/do/listTopics/projects.ggf-editor/discussion.rec_srm_interface_spec_v2_2
>>
>> although it isn't easy to navigate to this page from the GSM GridForge pages.
>> (at least, I couldn't see how to do it :-)
>>
>> I think the SRM-2.2 specification as it is written (i.e., as a spec.), has 
>> some areas it can be improved.  In general, I found the language too woolly 
>> and it would benefit from some sharpening (see comment in above link).  Using 
>> RFC 2119 vocabulary would be a good start, but the spec. really needs going 
>> through point-by-point.
>>
>> Another point is a more precise description in terms of states.  There seens 
>> to be an implicit assumption of objects having different states within 
>> SRM-2.2 (for example, files being near- or on- line), but the interaction of 
>> the API and the different object states could be better described.
>>
>> Perhaps describing these interactions in terms of state-transition diagrams 
>> would help ensure that nothing is left vague.
>>
>> Just my 2c-worth.
>>
>> Cheers,
>>
>> Paul.
>>   
>>     
>
> --
>   gsm-wg mailing list
>   gsm-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/gsm-wg
>