On Aug 31, Michael Behrens modulated:
2-cents: It is my understanding that EPRs can't by themselves be guaranteed to be unique or that bit-wise comparisons are unreliable considering canonicalization and embedded metadata issues. If so, then a unique AbstractName is needed in order to accurately resolve EPRs, especially considering the potential service migration. Instead of mandating, perhaps the speficiations can recommended the use of WS-Naming? Specifications could still accept EPRs and implementations can check them for the presence of an AbstractName and take advantage of it if available (internal hash table, etc).
I have to admit, I may not entirely understanding the different viewpoints in this ongoing discussion (ongoing at least since OGSI was unveiled in Toronto?)... but, there are many separable aspects to these notions of uniqueness and naming, and I get the impression that there are at least two camps who prioritize these aspects in different ways. I want to emphasize that I am personally sitting on the fence, but trying to reinterpret what everyone is saying! I would love to see comments on whether I am fairly portraying the different positions here... The major aspects are: 1. whether a reference avoids aliasing for all time, e.g. it either addresses a specific service/resource identity or nothing at all 2. whether a stale reference can be renewed to address a specific service/resource identity after migration etc. 3. whether references can be compared for a remote service/resource identity predicate 4. whether references can be remotely mapped or projected to a unique AbstractName I hesitated to use the word "reference" but cannot think of a more neutral term right now. I think that all the camps feel that (1) should be mandated for the Grid. I think (less certainly) that everyone feels that (2) should be optional for the Grid. This is what was proposed in the "renewable reference" draft. This is, for example, an EPR containing a resolver EPR. The major point of division falls on (3) and (4): There is one camp who place a high priority on having a global one-to-one mapping of AbstractName to service/resource identity. Such identity must be tied up in the stateful semantics of the service/resource. The opposing camp continues to argue two things: 1) that this is not really very important, and 2) that perhaps it is even misleading or impossible to have one universal notion of identity across different application domains, communities, or implementation technologies. The other major camp places a high priority on implementor and application freedom to use different reference formats. It considers that references always exist in some implicit relational model (maintained by applications, communities, etc.) where interesting or important identity attributes are maintained. As such, the references themselves do not need to express identity for interop. I note that there is an underlying clash in "worldviews" here between the camps. One camp considers AbstractName to be central to architecture with other reference/addressing data to be secondary implementation requirements---the reference/address data is to be resolved, refreshed, or discarded at will. The other camp considers reference/addressing data to be central to architecture with AbstractName or other identifying attributes to be secondary, domain-specific associations that might apply in one community or another. What I am struggling to answer for myself is: is there a sensible third camp that puts these two views on equal (neutral) footing, or do we have to adopt one view to make standards for interoperability? karl -- Karl Czajkowski karlcz@univa.com