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