[ogsa-naming-wg] Re: [ogsa-wg] Abstract names in BES

[Mark McKeown]

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