Sorry, I can not understand most of comments and statements here. Maybe explanation how most of these changes can improve understanding or schema definition would help. Michel Drescher wrote:
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
Sorry for my ignorance, why and when this may happen that "Similar jobs (who have a different namespace)"? Completely different? Can it be solved by using imported namespaces and extension mechanism?
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.
What does it mean referenceable? IMHO, you can reference with ID/Id attribute or with XPath or with xpointer any legitimate element in the XML document. Do you mean referencing schema elements/types?
- 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.
can you give an example what you mean by above?
- 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.
Sorry I can not understand how/why some elements are qualified as local and what is the incentive of using global vs local elements? If you are talking about definitions like <xsd:element name="Description" type="jsdl:description" minOccurs="0"/> this I can understand.
- 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
How above is related to the schema attributes elementFormDefault and AttributeFormDefault? What is the reason of limiting number of global elements? What is the benefits of having local elements? Does it help implementation/programming?
- 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
There should be some reason to group some elements except referencing them together. How many these cases of repeated definitions you have? Sorry I am really confused. Yuri
Cheers, Michel
------------------------------------------------------------------------
This text file carries explanations for the exammple given for the proposal of a new schema layout.
Package contents ================ job.xsd - the schema defining a simple JSDL inspired job structure example.xml - a sample XML document following the job.xsd schema exmple2.xml - another sample XL document following the same schema as examle.xml. Additionally it uses more advanced features like referring to elements defined in example.xml, and the usage of POSIXApplication that is part of the JSDL specification. readme.txt - this file
job.xsd ======= This schema defines a bunch of element types and elements. In particular and in order of appearance in the schema:
MemoryType ---------- A simple type of xsd:positiveInteger describing physical memory, in Bytes.
StorageType ----------- A simple type of xsd:positiveInteger describing any sort of storage, in Bytes.
CPUCountType ------------ A simple type of xsd:positiveInteger describing an amount of CPUs
ResourceGroup ------------- A xsd:group structure containing zero to three elements, each of type MemoryType, StorageType, or CPUCountType, respectively, so that each type occurs only once in this group.
ResourceType ------------ A complex type allowing elements of the group ResourceGroup. Additionally, it has an attribute of type xsd:NCName for the purpose of (possibly external) referencability.
ExecutableType -------------- A simple type defining how to speciify an executable.
ArgumenntType ------------- A simple type defining the structure of a command line parameter.
EnvironmentType --------------- A simple type defining the structure of environment variables
ApplicationGroup ---------------- A group collecting elements of type ExecutableType, ArgumentType and EnvironmentType. Same constraints from ResourceGroup apply.
ApplicationType ---------------- A complex type allowing elements of the ApplicationGroup to appear inside. Additionally, for referencability, it has an attribute "name" of type xsd:NCName.
JobType ------- A complex type defining the associations between Resources and an application. It defines two local elements "Resource" and "Application" (so that they do not need a namespace qualifier and cannot be root elements), both being complex types allowing elements of the group ResourceGroup and ApplicationGroup, respectively. They also define an attrbute of type xsd:QName each. Additionally, the local element "Application" allows for extension just as JSDL does (by allowing any XML element from other namespaces).
Jobs ---- This is the only globally defined element in this schema. Thus any document following this schema must have "Jobs" as root element. Jobs defines three local elements named "Resource", "Application" and "Job" that are of type "ResourceType", "ApplicationType" and "JobType", respectively. It also allows arbitrary attributes of any namespace.
example.xml =========== This sample XML document defines a set of resources named "AnySuitableComputer" (you will notice the inspiration from Igor's proposal...) and an application named "MonteCarlo" (same goes here...). It finally defines a Job that associates the resources "AnySuitableComputer" with the application "MonteCarlo". Note that the QNames must be given using the target namespace prefix ("ex" in this case) even if the referred elements are declared in the same document.
example2.xml ============ This example defines a customised version of example.xml. It uses the same set of resources, but overrides the value for Storage (since this version happens to need more storage space, for the sake of this example). Also, it uses the same application definition. Additionally, it uses a POSIXApplication extension to be able to use a POSIX specific version off the Monte Carlo simulation. This bit of this example is somewhat artificial since it now specifies two Executable elements and it is unclear which one the consuming system should use. But after all, it's just an example. :-)