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.