This is the summary of the other part of Igor's proposal. Basically, the proposal is that all elements inside Application should be done as extensibility elements except for ApplicationType and Description. Then, the other current (v0.9 of the doc) elements inside Application should be moved to another XML namespace that describes "executable" type jobs (i.e. jobs that are fundamentally the running of an executable even if that happens to be hidden away inside). Then, the other types of jobs (particularly web-services invocations and SQL queries) that have been mentioned involve other sets of extensibility elements inside. For the "executable" elements, I suggest the following namespace: http://www.ggf.org/namespaces/2005/02/jsdl-executable.xsd This should apply to the following elements: ApplicationName ApplicationVersion Argument Environment Error Executable Input Output ProcessCount TileSize WorkingDirectory The interpretations of these elements laid out in section 4.2.2.8 (under the 'executable' type) is correct and consistent. Other types that have been suggested to me which fit under this banner include 'bat' and 'dll' (both applicable to DOS/Win only; they're different types because they both really need different invokation sequences - 'cmd.exe /c <blah>' and 'rundll.exe <blah>' respectively - with these being details that it is usually a good idea to abstract away.) We need to add a note that the ApplicationType is *not* describing the format of the executable. (Thanks to Chin Chee-Kai for raising these issues.) Arguably, Limits should be done this way too, since they're only meaningful to executable-type jobs. For a "webService" invocation, the remaining body of the Application element (apart from the ApplicationType and Description) should be a normal SOAP envelope. The processing engine should use the JSDL Resource section(s) to decide where to run hand off the invocation to and update the SOAP header as appropriate (I think this is done by the wsa:To or wsa:Via elements, but we'll need to get this checked by someone who knows more than I do.) I don't know what to do about handling the response from the invocation. ;^) For a "sql" query, unless there is something already specified that we can use, I suggest that the following extra elements be defined in the namespace: http://www.ggf.org/namespaces/2005/02/jsdl-sql.xsd Elements: Query Parameter Output OutputFormat The Query element should contain an SQL query (formally as a string?). Following on from what I wrote yesterday on a document-oriented schema, it may also appear as a direct child of jsdl:JobDefinition, may be imported, and may have ref and name attributes. The query should be suitable for use as a Prepared Statement if any Parameter elements are present. There should be one Query as a child of jsdl:Application. The Parameter element may appear multiple times, and each represents a single parameter to a prepared statement set up using the Query element. Order matters (which is normal for these things it seems). The Output and OutputFormat elements (should the format be an attribute of the Output element?) specify where the result of the query is to go and in what format. (Is there someone else's spec we can use here?) I think that covers the summary of what's implied in Igor's proposal for splitting up the Application element's contents. Note that what I've written about SQL is not much more than a kite I'm flying. ;^) Donal.