Folks, from the last phone conference, I had the action assigned to follow the suggestion of naming elements. Based on some thinking and toying around, I propose the following layout: JSDL allows to define a) applications that are supposed to be executed, b) sets of resources that are to be consumed, c) files to be staged in and out and, finally, d) establishes associations between applications, resources and data sets. An exhaustive 3-tuple of associations is called "JobDescription". A JobDescription can also contain a set of identifiable elements serving various kind of purposes, such as accounting, billing, etc. These elements are aggregated in an element called "JobIdentification". All this is aggregated in a root element called "JobDefinition" (a name I would like to question, but more on this at a later point). This short description from a bird's eye view may not be totally new, but it gives some valuable hints on what is worth being referencable and what not: a) resources, b) applications and c) data sets. A JobDescription does not necessarily has to be referencable, since it is usually a unique association between other elements that, in this configuration, serve a unique purpose. It is adequatically specified through the document's namespace. Similar jobs (who have a different namespace) may want to use exactly the same set of resources or the same application etc. Most likely, however, the resource sets or applications etc. that have been defined for another job will not fit exactly the new job's needs, so a mechanism to tweak existing definitions could be handy. So, more technically and closer to the spec/schema, the following elements should be made referencable: - /JobDefinition/JobDescription/Application - /JobDefinition/JobDescription/Resource - /JobDefinition/JobDescription/DataStaging - Additionally, a similar mechanism exists for /JobDefinition/JobDescription/Resource/FileSystem and /JobDefinition/JobDescription/DataStaging/FileSystemID. I also propose to change FileSystemID to the type xsd:QName. - Following the convention used with the construct "xsd:group", I propose to use an attribute "name" of type "xsd:NCName" to make an element referencable. An attribute named "ref" of type "xsd:QName" is proposed to be used as a reference to a referencable element. - Sibling to JobDescription, applications, resource sets and data staging elements are allowed to be specified. They all get an attribute "name" of type "xsd:NCName" to be made referencable. - JobDescription defines local elements(!) with the same name (for applications, resource sets and data staging) and each gets an optional attribute named "ref" of type "xsd:QName" to refer to already defined elements (either in the same document, or externally). - These locally defined elements allow exactly the same appropriate groups of elements as the elements sibling to JobDescription. - Elements specified in JobDescription's local elements override elements with the same name in referred elements. - Finally, I propose to change the name of "JobDefinition" to something else, e.g. "JSDL" or something that does *not* have "Job" in its name since it does not define jobs alone anymore. (I just have no clue on a reasonable replacement.) The following proposals are of more concern to schema hackers and are related to technical issues of design and "taste". They can easily be skipped by others although they may touch higher level concerns: - I further propose to follow one of the two scenarios: a) define exactly one global element ("JobDefinition") so that any valid JSDL document always has "JobDefinition" as root element b) define a limited number of global elements, i.e. JobDefinition, JobDescription, Resource (rename to "ResourceSet"?) Application and DataStaging so that any valid JSDL document may have any of these globally defined elements as root element - Any other elements and types should be locally defined. Or do we want to allow i.e. "jsdl:NetworkBandwidth" to be root element? - Use xsd:group to group elements together and refer to these groups instead of repeating element definitions Cheers, Michel