[jsdl-wg] Validating JSDL documents

[Andreas Savva]

Thomas,

I'll put this topic on a teleconference agenda, though not tomorrow
because I think we won't have the time.

A comment after reading this fairly quickly is that when we did the
version 1 schema we chose not to use certain XML Schema features, like
substitutionGroup, which we thought might not be very well supported by
tooling. Things might have changed since. There were also substantial
disagreements on the 'right' way of defining the schema.

In any case, there is a roadmap (though not a schedule) for a version 2
and I expect that this is a discussion that we'll need to have in that
context.

Andreas

Thomas Soddemann wrote:
> 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