Dave, et al. On 22 Nov 2005, at 10:09, Dave Berry wrote:
The W3C guidelines on the use of URIs (and hence, I presume, IRIs) is that each resource should be identified by a different URI. URIs can be compared. URIs should not be reused to refer to different resources.
I don't know whether these guidelines are adhered to in practice, but on paper they seem to provide the uniqueness and comparison functionality that we require.
I found two perspectives on this. 1) In general these guidelines are adhered to in the WS world, but only because I think there is little experience with WS-Addressing. 2) The other perspective hinges on reversing the definition, i.e. a resource is that which is referred to by a URI. In this case the guidance is always adhered to automatically. Example: A search engine that gives localized results based on the IP address of the requester. In this case the W3C Arch line would be that the 'resource' is the same in all cases, but the address has an impact on the 'representation' that the requester sees of the 'resource'. The requester however perceives that they are different resources. Example: An EPR which relies on ReferenceParameters to disambiguate the the WS-Resource would, under (2) above, be interpreted as follows. The 'resource' would be the WS endpoint addressed by the was:Address. The 'WS-Resource' and the 'resource' are in this case different things. All the many WS-Resources accessed through the same endpoint are part of the same 'resource'. The problem is that the description of a WS-Resource and and a 'resource' (W3C Arch) are very similar, so the inconsistency is something to live/cope with.
The problem seems to be that WS-Addressing (or perhaps just some uses of it, e.g. some implementations of WSRF) breaks this nice system, by using the URI to name the access mechanism (the web service) rather than the resource being addressed. Frank has suggested on a couple of occasions that we specify how a unique address can be reconstructed from the wsa:to field and the parameters. Given this step, I would assume that the scenario that Frank considers here would not be permitted:
An EPR-minter can decide to create a new EPR for a resource and reuse an Address that was used for an other resource before.
So, I have many questions:
1. Is the above characterisation an accurate rendition of the W3C position on URIs and IRIs?
See above. It might help or merely confuse further.
2. Do we want stricter limits than the W3C?
The current use made of EPRs by some WSRF implementations is probably a bit loose as opposed to strict wrt the use of RPs to identify WS-Resources.
3. Can we profile WS-A as Frank suggests?
I don't think it is that easy, see earlier mails where RPs may or may not be used to disambiguate. We would probably need to define a named <ogsa:Disambiguator/> element it order to implement Frank's proposal safely, but I've not delved deeply into that yet.
4. If (3 and not(2)), does that satisfy our requirements?
Possibly, but subject to the above issues. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)