Oxana, The size of the documents is not indicative of the content. A good deal of the document is an attempt to succinctly extract the requirements from the GES document and give some background on the existing specs and profile. The only really substantive change to an existing specification is to BES - adding a new state, profiling sub-states (that have been discussed and documented before), and then describing how the existing specs (with the mentioned delta's) could be used to address the requirements. As an aside to the whole group. This next bit is rather embarrassing. I have not read the specification as published for some time (GFD.108). It turns out that my memory is not as good as I thought. First, the state model already includes Pending, and example profiles (but not formal profiles) for file staging, and suspend resume, are already in the document. Note that the createActivity takes an ActivityDocument which contains the JSDL, and has an extensibility point (element) that we could profile to include something like HOLD_PENDING (note that this is also where the document recommends subscriptions go as well.) Second, most operations ARE vector operations except for createActivity - which of course would need to become a vector operation as discussed. Third, notification subscription is already in the document - though it is a bit strangely put. Finally, it is not necessary to use RNS to get a list of activities, you can do that already using getFactoryAttributesDocument. We (the Genesis II team) recommend eliminating the ActivityReference element from the attribute document (it is a list of activity EPRs), and replacing that with RNS. We have found that for containers with a large number of contained activities, e.g., containers back-ended by PBS queues, that the size of the activities document grows out of control and rapidly leads to timeouts in the SOAP operation. Thus, the modifications are even less than I thought. A
-----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Oxana Smirnova Sent: Sunday, May 17, 2009 8:39 PM To: pgi-wg@ogf.org Subject: [Pgi-wg] Profiling vs new specs
Hi all,
and sorry for missing recent calls - was busy with other meetings.
You probably converged to some consensus regarding profiling and new specifications during one of the calls I missed - if you did, could you please outline the result?
If not, I'd like to compare pros and contras of each approach.
Andrew's "minimal changes" document advocating profiling seems to be larger than the GES strawman itself; this makes me wondering what is the definition of a "minimal change", and where is the margin when it is more efficient to introduce a new standard?
My major concern about profiling is that different profiles of the same standard may easily turn out to be incompatible, even if each was perceived as a "minimal change" by the authors. Then the very idea of standard compliance gets void.
I would prefer to avoid ambiguity as much as possible. There may be little semantic difference between different profiles of the same standard and different standards, but it can cause large practical implementation and operational implications.
Cheers, Oxana _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg