At Savas's behest , people are putting the boot in/providing valuable feedback on the WS-RF specification. I may provide something too.

Having implemented a WSRF endpoint (remember the demo last week Mr Parastatidis?), I can state that the readable/writeable properties bit is quite nice. Only, you should have a meta-property to list all other available properties, and it is left open whether bulk get/set is atomic or not. It certainly isn't on mine.

The issue of controversy that Mark Baker picks up on is why have URL+properties to define a resource, when a suitably unique URL will suffice. I have another take on it, which is that using a URL hoses your fault tolerance, and that URIs are better than URLs there.

Based on the experience of implementing it, the issue I have with reference properties is that all WS-A implementations have differently bad support for everything other than the core URI. I am not going to blame the implementors here, because in the absence of a single normative WS-A test, it is impossible to formally declare compliance. That is: the only bit of the WS-A address that can reliably refer to a resource and work across implementations is the URL. Anything else may or may not work, but you are on your own.

Therefore, in any implementation of WSRF that is broadly callable by arbitrary SOAP stacks, having the URL==the resource is the only viable option, fault tolerance notwithstanding. I have expressed some concern about this to the OGSA mail list