Hi Chris,
Well, I also believe that it's better to keep the IRIs opaque and was suggesting to use the complete IRI itself as an alternative jobId.
Whether that could work depends on the use cases we have to consider...
See this is exactly what I want to avoid.
Our customers are used to seeing a regular jobID (now if this is generated by a higher level scheduler that understands checkpointing and migration and the fact that lower level jobids might change, that's fine). The use this jobID within command line tools and web portals to access information about their job. The web services interfaces are now an additional interface to these others. Why should I bring WS baggage along (in the form of EPRs and IRIs as identifiers) when I have one that our users understand already. I don't want to have to retool my CLI and other existing interfaces to now take some other structured identifier.
The abstract name seems to me like a nice way of providing this identifier in the context of the WS interface. Sure, many of the alternative proposals would do the trick as well, but I had always been under the assumption that clients weren't supposed to interpret the EPR elements.
A client can examine an EPR, for example an EPR can contain Meta data about itself. However a client should not examine any ReferenceParameter an EPR may contain, ReferenceParameters are ment to be opaque. http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/#eprinfomodel cheers Mark