[jsdl-wg] Assessing Igor's Proposal

[Donal K. Fellows]

Thanks Igor for your submission. Unfortunately it needed enough
consideration that it couldn't be discussed at the telecon on the 18th
(all we could really do was acknowledge its existence and tell me to
study it further) but here's some impressions from a, well, second run
through. :^)

[BTW, it seems sometimes below like I think not very well of you, Igor.
This isn't true. I'm just coming to the problem from quite a different
direction so my perspective is quite at variance. So don't get cross!]

By major point in Igor's proposal:
 > 1) Provide a documented-oriented schema

I do not entirely understand what this is in comparison to what we've got.

 > 2) Provide naming for external reference support

I've no objection in principle to this, but I wonder how it interacts
with what we use 'id' attributes for internally (which I know is quite
unusual in the XML world, especially as they aren't of xsd:ID type).
Perhaps they'd be better off called 'name' attributes anyway. :^)

Note that the JSDL Profile semantics require non-uniqueness of names.
More on this later.

 > 3) Make everything externally referencable

I'm much less happy with this; the various parts of a JSDL (especially
if you omit the Profiles) are not generally seperable, and Profiles only
really make sense when applied to a particular JobDescription. Given
that, it is the JobDescription that is of most interest as far as I can
see. However that's a singleton in a JSDL document, so I'm not sure how
useful it is to be able to refer to it independently of the document.
None of this prevents someone from defining their own language which
includes elements from JSDL. :^)

Note that I suspect that what I've just said is fairly likely to be
controversial. If anyone has a different opinion, please speak up!

(The throwaway comments about a CIM XML schema amused me. CIM really
isn't organized in a way to make such tasks easy.)

 > 4) Rearrange the term structure

I'm not keen on rearranging the structure so that Resource, Application,
User and DataStaging elements appear outside JobDescription and Profile
elements. But grouping the various subtypes of Application contents
together into their own namespaces seems much more reasonable. I'm not
sure how much is going to be shared (and hence in the master namespace)
at this stage...

Given all that, even the outline of structural changes you propose feels
semantically "violent" to us as it potentially denudes elements of their
basic context. :^)

5) The conclusion

Some of the points made in that conclusion are somewhat of a red-rag to
a bull. Given that we already have a document structure and rules (and
reasons for that structure and its associated rules) it feels more than
a touch condescending.


OK, back to Profiles. Profiles are groups of restrictions, alternatives
and clarifications for aspects of a Job (e.g. so you can describe how to
run it on both SMP machines and clusters) and they don't specify the
whole of a job. In theory, you could keep them in a separate document
from the JobDescription element I suppose, but I can't see why because
there is no reason at all to suppose that any Profile would be
applicable to multiple jobs. There is absolutely no reason to be able to
name separate components of a Profile; the names are there for a
separate reason.

The Fundamental Model of JSDL Profile Processing: When applying a
Profile to a JobDescription, the matching is done first by type of
component element of the profile and then by name/id of the element.
This allows for both replacement of elements and adding to lists of
elements, both behaviours that are useful. (I've probably messed up the
description here). When a Profile is applied, it must always be applied
in its entirety though an accepting JSDL processing agent always has a
free pick of what profile (from those supplied) to apply. (By contrast,
expanding JPAs add profiles, so allowing software agents like resource
brokers or superschedulers to apply domain-specific knowledge to a job
instead of requiring primary JSDL authors to understand the entire state
of the system.) The end-point of such processing is a profile-free
document that is consumed by something like a batch queue and which is
taken as directions to execute a particular job.

Does anyone else have anything to add? Please? :^) And have I missed
anything significant or read too much into what was there?

Donal.