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. :-)