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

[Christopher Smith]

On 10/11/05 10:35, "Frank Siebenlist" <franks at mcs.anl.gov> wrote:

> Mark McKeown wrote:
>> Hi Donal,
>> 
>>   
>>>> Regarding Chris's desire to be able to pass the LSF jobid
>>>> back to the client somehow - it could be included in the EPR's
>>>> Metdata, possibly RDF could be used to mark up the Metadata
>>>> to indicate that it is a LSF jobid. In this way the Address
>>>> IRI can be kept opaque.
>>>>       
>>> That would seem to me to be needless disambiguation. Surely it is just
>>> up to the service that mints the abstract name to understand it; there
>>> is no inherent need for it to explain what that means to anyone else.
>>>     
>> 
>> I am not sure I understand your comment - you don't seem to
>> be disagreeing with me...
>> 
>> Frank wants to use the EPR's wsa:Address IRI as an AbstractName,
>> Chris wants to send a LSF jobid to the client and the W3C
>> recommends that IRIs should be opaque. One way to include
>> the LSF jobid in the EPR is to embed it into the wsa:Address
>> IRI, this might help make it unique and the client could extract
>> it from the IRI - however the W3C recommends that IRIs
>> should be opaque.
>>   
> 
> 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.

-- Chris