[jsdl-wg] JSDL compliance levels

[Ali Anjomshoaa]

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 at epcc.ed.ac.uk
        Edinburgh EH9 3JZ               Phone:  + 44 (0) 131 651 3388
        United Kingdom                  Fax:    + 44 (0) 131 650 6555
        -------------------------------------------------------------