Marvin Theimer wrote:
So to summarize...
----------------
There are four implementation options that should be supported by the
spec for obtaining public state data:
1) WS-Transfer,
2) WSRF,
3) public state accessor operations,
4) basic interop.
An accessor operation for obtaining the activity status MUST be included
in each of the above implementation options.
Official QNames SHALL be defined for options 1-3.
The GetInteropData operation MUST return a list of QNames that
represents which of the above options is supported. An empty list
implies that ONLY option #4 is available.
----------------
We should also define what port types option #2 implies or break it up
into three different options for each of the three port types used for
resource property queries in WSRF (wsrp:GetResourceProperty,
wsrp:GetMultipleResourceProperties, and wsrp:QueryResourceProperties).
This sounds good to me. I presume that “basic interop” means just the two accessor operations for activity status and complete activity infoset?
I was only including the status getter:
An accessor operation for obtaining the activity status MUST be included
in each of the above implementation options.
In terms of absolute bare minimum interop, I don't think a public resource data getter is necessary. The implementation can still provide a getter operation for the public resource data, but the assumption under basic interop is that it is not a standard the spec knows about or chooses to support. Basic interactions can still occur. It's just that a client not built specifically for the implementation won't be able to inspect the more detailed information about the services. Peter
Marvin.