First, please allow me to say something about my claim that the OGSA WG mandates WSRF, a claim which you have questioned. I may have misunderstood the group's intentions, in which case I apologise, but discussions with various people and minutes from meetings directed me and many others towards making that conclusion (this was raised by several people at the UK-OGSA meeting). Also, the current draft of the OGSA Basic Profile, to which I assume all high-level services will have to adhere, is described in terms of WSRF.
Savas: What I meant about "mandating" (which upon reflection I suspect is what you meant too): A profile typically says simply that IF you use something, THEN this is how you must use it. It doesn't say you MUST use it. Thus, the OGSA Base Profile doesn't say anything about whether WSRF should be used or not, it just says how you should use it if you do. Where, then, is WSRF "mandated"? At present, nowhere. However, moving forward, it would seem likely that when OGSA WG considers say a management specification for inclusion in some future "management profile", it will look kindly on one that uses WSRF conventions to access remote state, rather than making up its own custom ones, because that is viewed as enhancing interoperability. It would then also want to see that WSRF is used in a way that adheres to the OGSA Base Profile. On the other hand, when considering specifications that have nothing to do with state (e.g., naming), there would be no reason for WSRF to come into the picture. The draft OGSA Naming Profile that Andrew Grimshaw is developing does not use any WSRF mechanisms. It *could*, but this hasn't been seen as particularly useful, so it doesn't. And (the point I was harping on, probably too much), there is nothing to say that you must use WSRF conventions when developing your own services. So, I guess WSRF is "mandated" in some places, and not in others. Steve Loughran wrote more eloquently on some related topics in an earlier post to ogsa-wg. Ian.