[ogsa-wg] OGSA Glossary v1.6: Final Call

Treadwell, Jem jem.treadwell at hp.com
Thu Dec 6 22:30:11 CST 2007


Hi Donal, thanks for your comments... responses embedded with JT>:
Minor points.

  Attribute - should be in there, as link to 'state'.
JT> I'm not sure that this has a technical meaning that needs defining - I think we use it with its normal dictionary meaning. If it means the same as state then we don't need it, and I'd hate to endow it with some special meaning that would limit its use. And in fact we do use it extensively as a dictionary word to help define state, so a separate entry would introduce circularity.
  Entity - should mention that entities may have state.
JT> This word came up for discussion following in public comment, and we agreed to review it for the Architecture doc. We have a tracker for it, and I've added this comment to the tracker. The tracker is at https://forge.gridforum.org/sf/go/artf6087?nav=1.

  Self-management - the second paragraph sounds like an advert. Maybe        this can be fixed through minor wordsmithing so that the it says that "A self-managing IT infrastructure _should be_ less complex etc."
JT> Agreed - it seems to be a justification, rather than an objective explanation of the term. Recently our approach has been to remove examples if they don't obviously help to explain, so I've taken the same approach with this, and deleted the second para (currently only in my local copy). If anyone objects, please let me know.
  TCP - the definition omits the important fact that this protocol         provides a stream-oriented model (i.e. a sequence of bytes) of data transfer to applications.
JT> Agreed: I've changed this to say "A packet-level, stream-oriented protocol used to exchange data over the Internet."

More significant point.

The definitions of EPS and CSG are at variance with what the OGSA-RSS-WG has interpreted them to mean. Of particular importance is the fact that we have identified the requirement for an abstract notion of a set of candidates for some particular activity or interaction, independent of whether that activity relates to execution management (and which is what we named a CSG). We then made an EPS into a profile of a CSG such that it is useful for execution management.

JT> I agree with Andreas, we should defer this for review with the OGSA Architecture. I've opened tracker 6096 for this.

Thanks as always - let me know if you disagree with any of my responses.
- Jem


> -----Original Message-----
> From: Andreas Savva [mailto:andreas.savva at jp.fujitsu.com]
> Sent: Thursday, December 06, 2007 8:17 AM
> To: Donal K. Fellows
> Cc: Treadwell, Jem; ogsa-wg
> Subject: Re: [ogsa-wg] OGSA Glossary v1.6: Final Call
>
> Donal,
>
> > More significant point.
> >
> > The definitions of EPS and CSG are at variance with what the
> > OGSA-RSS-WG has interpreted them to mean. Of particular importance is
> > the fact that we have identified the requirement for an abstract
> > notion of a set of candidates for some particular activity or
> > interaction, independent of whether that activity relates to
> > execution management (and which is what we named a CSG). We then made
> > an EPS into a profile of a CSG such that it is useful for execution
> > management.
>
> Though this is true,  the Glossary is a pair of the Architecture
> document and the definition of EPS & CSG in version 1.5 are different
> from those of RSS. Since we are publishing the Glossary out of step of
> the Architecture document there's bound to be a discrepancy somewhere. I
> would prefer to minimize that discrepancy by leaving the Glossary
> definitions as they are and putting an issue against the Architecture
> document, to be fixed at the next release. Is this acceptable?
>
> Also
>
> >   Entity - should mention that entities may have state.
>
> My preference would be not to try and say too much about what 'entity'
> is. It's one of those terms we use when there's no other easy term to
> use...
>
> Andreas
>
> Donal K. Fellows wrote:
> > Treadwell, Jem wrote:
> >> If you have comments please let me have them by CoB this Friday,
> >> December 7^th .  If any comments are minor (e.g. typos, formatting,
> >> minor wordsmithing) I'll incorporate them and submit the document for
> >> publication next Monday, December 10^th .  If I receive more serious
> >> comments I'll ask Hiro to schedule time for discussion on an upcoming
> >> telecon, at which we'll agree either to address them before publication
> >> or to create trackers and defer them for the next version.
> >
> > Minor points.
> >
> >   Attribute - should be in there, as link to 'state'.
> >
> >   Entity - should mention that entities may have state.
> >
> >   Self-management - the second paragraph sounds like an advert. Maybe
> >         this can be fixed through minor wordsmithing so that the it says
> >         that "A self-managing IT infrastructure _should be_ less complex
> >         etc."
> >
> >   TCP - the definition omits the important fact that this protocol
> >         provides a stream-oriented model (i.e. a sequence of bytes) of
> >         data transfer to applications.
> >
> > More significant point.
> >
> > The definitions of EPS and CSG are at variance with what the OGSA-RSS-WG
> > has interpreted them to mean. Of particular importance is the fact that
> > we have identified the requirement for an abstract notion of a set of
> > candidates for some particular activity or interaction, independent of
> > whether that activity relates to execution management (and which is what
> > we named a CSG). We then made an EPS into a profile of a CSG such that
> > it is useful for execution management.
> >
> > Donal.
> > --
> >   ogsa-wg mailing list
> >   ogsa-wg at ogf.org
> >   http://www.ogf.org/mailman/listinfo/ogsa-wg



More information about the ogsa-wg mailing list