Folks, this is regarding my action to review Michel's proposal re: JSDL compliance levels. I agree with Michel that we don't need "levels" of compliance. All supporting systems MUST be able to understand and parse all of JSDL. I don't believe that we need say anything regarding how a system satisfies the requirements, after all, we can't police "JSDL compliant" systems, and the semantics should be clear enough that system implementors know what to do to set up a job environment based on the specified requirements. Is that clear, or do I need to explain more? I propose the following for the end of Section 2 (based somewhat on Michel's proposal): ---------------------------------------------------------------- The term JSDL document refers to a well formed XML document that can be validated against the normative JSDL Schema definition contained in Appendix 2: Normative Schema. The terms JSDL element and JSDL attribute indicate that the corresponding language construct is represented as an XML element or an XML attribute, respectively, in the normative JSDL Schema. The key word present, with respect to a JSDL language construct being present, refers to an instance of that construct being present in a JSDL document. The key word support, with respect to a JSDL consuming system supporting the JSDL specification and the language constructs, refers to the ability of that system to parse a JSDL document. That is, the consuming system must be able to interpret the language constructs and assign to them the semantics described in this specification and the values assigned to them in that JSDL document. All JSDL consuming systems must, therefore, support all of the JSDL language constructs. ---------------------------------------------------------------- With suitable formatting. Cheers and take care, Ali On Tue, 19 Apr 2005, Michel Drescher wrote:
Folks,
I got the assignment to the following two action points from last week's phone conference:
8) JSDL compliance levels How much of jsdl a system must support, not just process. Probably a topic for later.
9) The statement "If not supported then the consuming system MUST reject the document." needs a bit more explanation or re-write
To solve these action points, I refer to the specification document (v0.8.5-02) ch 2 "Notational conventions".
I propose to replace the chapter's last three paragraphs (the text after table 1) with the following paragraphs:
"The term JSDL documentrefers to a XML document that has been created following this specification. It is a schema instance document derived from the normative schema definition inAppendix 2:Normative Schema.
The terms JSDL element and JSDL attribute indicate that the corresponding language construct is represented as an XML element and XML attribute in a JSDL document.
The key word presentrefers to a construct being present in a JSDL document.
The key word support refers to a consuming system being able to apply the following functions to a JSDL element or JSDL attribute: � Parse the JSDL element or JSDL attribute into a DOM tree � Validate the parsed DOM tree against the appropriate schema(s) � Interpret the JSDL element or attribute and assign the semantics according to this specification.
The JSDL specification does not require the consuming system to actually implement the semantics of JSDL elements and attributes, so that the described job is executed on a computing system.
A consuming system MUST support all normative JSDL elements and JSDL attributes. If a consuming system implements JSDL, it MUST implement all defined JSDL elements and attributes.
This allows not only systems that execute jobs but also systems that provide higher level services, for example job broker, super scheduling systems (that possibly change JSDL documents before they get submitted to lower level job execution systems), etc."
Note: The last paragraph possibly fits better in a JSDL primer document.
This way any consuming system that deals with JSDL must support the defined JSDL elements and attributes, but it does not need to "ground" or "incarnate" or even execute a JSDL job. But if it implements JSDDL, then all JSDL elements and attributes must be implemented. So this basically eliminates any JSDL compliance levels. As we already reduced JSDL to the lowest common denominator, there is no need of compliance levels at all - at least for the moment. The consequence would be that we can delete all these "If not supported then ... " sentences.
Cheers, Michel
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------