Hi;

Yes, this is how I see things as well.  Extensibility means that CreateActivity must be able to include an extensible set of parameters.  The details of whether these are extensions to the interface WSDL or extensions to one or more infosets that represents the parameters of CreateActivity is to be determined.  But the key idea is that a simple, basic version of CreateActivity can be defined in the spec and that we have a clean way to add optional extensions to the functionality of CreateActivity, such as delegated credentials, subscription requests, create-in-suspended-state, etc.

Marvin.

-----Original Message-----
From: owner-ogsa-bes-wg@ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On Behalf Of Peter G. Lane
Sent: Thursday, June 29, 2006 10:37 AM
To: ogsa-bes-wg@ggf.org
Subject: [ogsa-bes-wg] Job Template vs. Job Instance Options

I was enlightened today on the telecon to the opinions of those of you

who see a clear distinction between the activity template (JSDL) and

activity instance options. I'm fine with that, although thinking about

this I realize that we need extensibility, then, also in the

CreateActivity operation.

As a specific example, GRAM needs to access delegated credentials.

Security requirements are out of scope of the OGSA-BES spec, but EPRs

pointing to credentials clearly are in the activity instance category

rather than the activity template category. The only way not to violate

the above philosophy is to add an xsd:any (minOccurs="0"

maxOccurs="unbounded" namespace="##other") to the parameter list of

CreateActivity. Putting these extensions in the JSDL document isn't

appropriate.

This could also be a better solution for things like the subscription

request and the CreateInSuspendedState parameters. They would

essentially be out of scope of the spec, but not forbidden. I think that

would appease those who don't like it specified in the spec given that

not all implementations will want to have that feature or the exact same

feature.

Peter