Andrew: I'm not ignoring you: either I hadn't heard you express the use cases below (I haven't been on all the calls) or I hadn't internalized you doing so. I appreciate you taking the time to write them down: this information is very helpful. Three comments on the use cases: 1) These use cases, like Chris Smith's, do not imply a need for names that are "globally unique in time and space." The only requirement is that names be unique with respect to the scope of the activities that the user wants to monitor or track. This might seem a minor point, but I think it's an important one: as Chris pointed out, a sensible key to use as a name in #1 could be, in some circumstances, e.g. the LSF jobid. That choice of key is prohibited by the current WS-Name definition. 2) In use case #1, I think you assume that a notification has the form "job with epr E has status S." Certainly, if that was the case, then you'd face the problem of determining which job that EPR referred to, something that you can't do without the ability to compare EPRs. But in WS-Notification, at least, when a client subscribes to notifications it can supply, as the callback address, an EPR to a unique WS-Resource. So the notification delivers the message "status S" to the subscription for job with epr E. Thus, there is no need to include a key in the EPR for the purpose of disambiguation. 3) Use case #2 makes sense to me. I could also do this without an AbstractName, by passing around an XML structure containing an application-specific key and the EPR--or, more likely, embedding the EPR in a larger application-specific structure that I have created for other purposes. But clearly an AbstractName could usefully be applied here. Ian. At 12:03 PM 11/16/2005 -0500, Andrew Grimshaw wrote:
Ian,
I did give a scenario you just chose to ignore it. Here are two:
1) As a client of BES I want to be able to keep track of the activities I start. Suppose I have one hundred going. I want to build a data structure that keys off of the activity. Id like the handle I get back from the BES container (which is basically acting like a factory) to have a keyin it I can use so that when I get notifications about the activity, or some other services wants to talk about the activity I have some way to associate and search for the activity information I am keeping.
2) Using the WS-name (specifically the abstract name) to correlate information flows about an activity. (This is the example I have used several times.)
The requirement in both cases is to be able to identify when two EPRs refer to the same activity.
Andrew
---------- From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Wednesday, November 16, 2005 9:33 AM To: Hiro Kishimoto; Andrew Grimshaw; Tom Maguire; Frank Siebenlist; Smith Chris; Mark Morgan Cc: Savva Andreas Subject: Re: naming issues resolution process discussion (Re: [ogsa-wg] Proposed agenda for Nov. 16 call)
Hiro:
Ahead of the call, I'd like to raise the question again of what application requirements motivate the use of WS-Names in BES. I asked this on the last call, and my question wasn't answered. I asked the question again via email, and Chris replied with what turned out to be a requirement for something different than WS-Names. I think it would be really helpful to have a list of requirements as a basis for discussion.
Ian.