Frank Siebenlist wrote:
...
By advocating using the Address element of the EPR as the AbstractName are you saying that ReferenceParameters should NOT be used to map messages to backend resources? (Two WSRF EPRs can have the same Address element but use ReferenceParameters to map to different WSRF resources)
I'm afraid that my own preference shown through here as life would be simple with just IRIs ;-)
...but no, I realize that the ReferenceParameters will be used to carry the dispatch info.
In the past I've given a recipe how one could construct an identifier/name from the address+refParameters by essentially concatenating the Address value with some base64 blob of the canonicalized refParameters (or if space is a consideration, append the digest value of the refParmeters...)
This transformation essentially would give you the Address value as the name when no refParameters are present.
For this to work, the transformation should be standardized such that all parties can generate the same IRI-name, and it still requires a profile on the uniqueness properties for the combined Address+RefParameters for this to be a useful name (URN).
I realize that it could cause confusion, but in this discussion, whenever I use the Address as a name, it is essentially a simplified version of what I stated above. In other words, for the discussion we can ignore the referenceParameters and pretend they don't exist ;-) -Frank. -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory