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.