Attached are the diagrams for the scenario I wrote in below. Thanks Sachiko for drafting this. -Keisuke Keisuke Fukui wrote:

Although I haven't thought well about this, attached is the additional comments from Steve.

Considering the url has flexibility to accommodate various protocols and indeed concise method to specify the location to the contents, here is an hypothetical sequence for the content retrieval:

1. The repository should expose a list of protocols supported, 2. then the client chooses a preferred one from the list and specify it as a parameter in GetContents, 3. then the Repository returns a url that fits to the specified protocol. 4. the client should resolve the reference (i.e. get actual contents) from the url.

We don't need to be bothered how we can translate the arguments parameters to GetContents, rather we say returned url is opaque except for protocol portion. The url may vary depending on the protocol the client specify. We can include Soap_with_Attachment in the list of supported protocols, for example:

supported_protocols = { SwA, file, http, https, ftp, ... }

Then the repository can return the contents as a response message for the GetContents instead of url.

We can do the similar for other interface such as Register/Create. Thus, we can formalize the interface and still accommodate the various protocols that may be provided by the repository implementation. Does this make sense? Or is there better way to specify the interfaces?

-Keisuke