[ogsa-bes-wg] draft ESI 0.7 OGSA WSRF BP rendering

[Michel Drescher]

Peter,

I used the attached document.

Cheers,
Michel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-ggf-esi-0.7.doc
Type: application/octet-stream
Size: 932352 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060428/6b41a68b/attachment.obj 
-------------- next part --------------

On 28 Apr 2006, at 17:30, Peter G Lane wrote:

> On Fri, 2006-04-28 at 16:39 +0100, Michel Drescher wrote:
>> Hi Peter,
>>
>> I'm referring to spec v0.7 in my inline comments:
>>
>> On 28 Apr 2006, at 16:19, Peter G Lane wrote:
>>
>>> Great start! Just a couple of comments:
>>>
>>> 1) I'd prefer something like "ManagedJobFactoryResourcePropeties"
>>> instead of "JobFactoryRPDocument". That way everything is spelled  
>>> out
>>> and it's named after the full port type name.
>>
>> Referring to 3) below, I would suggest
>> "JobFactoryResourcePropertiesDocument" (or
>> "JobFactoryResourcePropertyDocument"?), reconciling your and my
>> suggestions.
>
> "JobFactoryResourcePropertiesDocument" is fine with me.
>
>>
>>> 2) I think the unnamed complexType under the "JobFactoryRPDocument"
>>> element should be named. Following my preference from #2, this is
>>> what I
>>> would like to see (or something similar):
>>>
>>> <xsd:element name="ManagedJobFactoryResourceProperties"
>>> type="tns:ManagedJobFactoryResourcePropertiesType"/>
>>> <xsd:complexType name="ManagedJobFactoryResourcePropertiesType">
>>> . . .
>>> </xsd:complexType>
>>>
>>> This is primarily motivated by implementation concerns, but it's not
>>> like working around broken tooling. I just don't like leaving class
>>> names up to the tooling. Specifying a name explicitly usually  
>>> dictates
>>> what it will be seen as in the API. In addition, it mandates that  
>>> any
>>> reuse of the element be done via a ref (like Subscribe).
>>
>> Agreed, according to the notes from 1).
>>
>>> 3) The port type name is specified as "JobFactoryPortType"  
>>> instead of
>>> "ManagedJobFactoryPortType" from the spec. If this was something
>>> decided
>>> upon in the last call I apologize.
>
> I think we might be talking about different documents. I'm attaching
> what Ian posted to GT's gram-dev mailing list. He didn't send a UML
> diagram with it, so my comments are also straight from the text. Could
> you attach or post a link to the document you all are using. Thanks.
>
> Peter
>
>>
>> I took it directly from the section headings (section 4) and not from
>> the UML picture in figure 1 (page 5)
>> I guess pictures get easier out of sync with draft specifications in
>> much flux, so I preferred the section headings.
>> Also, I think "ManagedJobFactory" could be misinterpreted as a
>> JobFactory that is managed which would lead to the wrong assumptions.
>> But I am probably nitpicking here.
>> The point is that I have no trouble changing it, if necessary.
>>
>> I attached the updated versions below.
>>
>> Cheers,
>> Michel
>>