Peter Lane wrote:
I also think the ID attribute is perhaps redundant. JobIdentification has a JobName element that seems like it should be sufficient for uniquely identifying a subjob. Or is this not how the authors envisioned JobName's use?
Actually, the problem with an ID attribute is more subtle, in that the uniqueness constraint upon it is defined purely at the document level. In the world of XML documents living at URLs, the wider disambiguation is done by the URL of the overall document, but that's not useful with JSDL because job submission templates will typically not have a (fixed) URL before the submission. I suspect that to fix this we need a GUID *somewhere* in there, and that the source of the GUID has to be either the user or (more likely) the client software that injects the JSDL document into the system. That would allow JSDL consumers to know unambiguously whether they've seen the document before without having to do a full canonicalize-and-compare. With a bit of work[*], I might even come up with a scenario where a full comparison would fail despite two JSDL documents really being the "same" in some higher-level sense. Things get quite complex when you have job rewriting/optimization services in the mix, but a GUID lets the "what is identity" decision be taken at a the outermost - and hence most abstract - level. Donal. [* Which I'd rather not do, being somewhat lazy. :-) ]