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

[Peter G Lane]

Ok, these are basically the same. I believe I understand now what you
meant by the UML document--the embedded diagram. It seems that the
document in general is a little inconsistent about whether it uses
"ManagedJob" (i.e. CreateManagedJob) or just "Job" (i.e. "Job Factory
Interface"). IMHO this needs to be reconciled. Either use "Job Factory
Interface" and "CreateJob", for example, or "Managed Job Factory
Interface" and "CreateManagedJob".

Anyway, that's all. Ian has a bunch of spec comments from me already, so
I won't go into anything else about the spec right now.

Peter

On Fri, 2006-04-28 at 17:38 +0100, Michel Drescher wrote:
> Peter,
> 
> I used the attached document.
> 
> Cheers,
> Michel
> 
> 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
> >>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3720 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060428/ccf39809/attachment.bin