Dear Group,
within the DEISA project we have a new Web Service - SaaS project.
With that we are faced with task of providing means for the
interpretation of JSDL documents including its standard extensions.
When working on this project, we naturally had a close look at the
JSDL specification and the provided JSDL schema definitions (meaning
JSDL 1.0 which we will refer to as the "core" XSD and the three
extensions, POSIX, HPCPA, SPMD).
Accepting JSDL documents means certainly verifying them syntactically
and in a second step semantically. But due to the use of xsd:any and
xsd:anyAttribute tags at various places in the core XSD, it is not
possible to perform a syntactical verification of a document on the
basis of the given schemata alone. Extra code is needed to check the
correct position of elements from the extension name spaces.
When reading the section of the specification which describes how to
extend JSDL we got the impression that xsd:any and xsd:anyAttribute
are used as hooks for extending JSDL.
The problem implementors like us have now, is the extra code which is
needed to check the validity of JSDL documents arising from the use of
the any tags. More code means a greater risk of bugs.
In addition this extra code may also lead to non-interoperable
behavior due to misinterpretations of the specification document(s).
Hence, should it not be the ultimate goal for the JSDL-WG to formulate
a schema definition which allows extensions but also requires this
extensions to inherit and adhere to the intended structure? Only then,
it would suffice to perform a simple XSD validity check on a given
JSDL document in order to determine its syntactical validity.
We think, it is conceivable to modify the existing JSDL schemata to
fulfill the above requirement with only minor modifications to the
JSDL spec itself.
First of all, JSDL core spec extensions can always extends JSDL
elements, since none of them is marked as final. This already does
enable extensions to define additional elements and attributes without
the need of exploiting xsd:any and xsd:anyAttribute.
Furthermore, it still should be possible to include serveral
extensions (at least as sub-elements in Application, and may be also
in JobIdentification, Resources, and DataStaging). This can be
achieved by introducing an optional abstract element to these elements
in a prototype pattern manner.
An example for Application could be
<xsd:complexType name="Application_Type">
...
<xsd:element ref="ApplicationPrototype" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:complexType>
which could be implemented as
<xsd:complexType name="ApplicationPrototype_Type">
<xsd:sequence>
<xsd:element name="application" type="ApplicationPrototype_Type"
minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="applicationRef" type="xsd:IDREF" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
</xsd:complexType>
<xsd:element name="ApplicationPrototype"
type="ApplicationPrototype_Type" abstract="true"/>
Extensions like SPMD then would simply extend ApplicationPrototype
<xsd:complexType name="SPMDApplication_Type">
<xsd:complexContent>
<xsd:extension base="jsdl:ApplicationPrototype_Type">
<xsd:sequence>
...
</xsd:sequence>
<xsd:attribute name="name" type="xsd:NCName" use="optional"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="SPMDApplication" type="SPMDApplication_Type"
substitutionGroup="jsdl:ApplicationPrototype"/>
and an according JSDL document snippet still would read as
<Application>
<ApplicationName>Whatever</ApplicationName>
<ApplicationVersion>1.1b</ApplicationVersion>
<jsdl-spmd:SPMDApplication >
<jsdl-spmd:NumberOfProcesses>128</jsdl-spmd:NumberOfProcesses>
<jsdl-spmd:ProcessesPerHost>32</jsdl-spmd:ProcessesPerHost>
<jsdl-spmd:ThreadsPerProcess>1</jsdl-spmd:ThreadsPerProcess>
<jsdl-spmd:SPMDVariation></jsdl-spmd:SPMDVariation>
</jsdl-spmd:SPMDApplication>
</Application>
but could be verified syntactically in simply using schemata.
For achieving such a goal, a few steps would have to be done.
* all occurrences of xsd:any and xsd:anyAttribute elements would
have to be removed from the specification
* the "Extending JSDL" section in the specification would have to be
rewritten
* the standard extensions would have to be augmented by adding
inheritance to match the above structure
* xsd:any and xsd:anyAttribute elements may be removed from the
standard extension XSDs as well.
Your comments on this are very welcome.
Best wishes,
Thomas
