Yes, I had imaginged that it would be a pass through mechanism of
sorts. There has been some work on dealing with specific fixed
formats, for example, RSS and ATOM, in the REST environment in SCA. So
you could consider these to be representative of bindings that deal in
concrete and fixed body types. I'm not suggesting that they are
repurposed in any way just put them up there as a contrast.

I don't know how the path info/body information should be presented. I
Assume that there are limited types of data that can arrive in the SCA

   Params on URL
   Form params on URL or Body (x-www-form-urlencoded)
   XML in body (xml)
   Form params on URL or Body (x-www-form-urlencoded)
   XML in body (xml)

We could take take the view that the CRUD interface is generic and
that we need to be able to pass this data into each method in a
generic way, e.g. parameter arrays, stdclass, generic SDO, simpleXML
etc. I'm also interested in allowing people to use SCA to define what
type they are expecting. Maybe this sits between being a pass through
and a specific encoding. I.e. it's a specific encoding for a
particular service but the binding is not restricted in the types on
encoding that can be specified.

On the return we need to allow either a simple or complext type to be
returned. In this case I think we can take the approach we have taking
before of allowing simple types or SDOs to be returned.

The other thing we need to support is the various HTTP error codes
that can be generated.



You received this message because you are subscribed to the Google Groups 
"phpsoa" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to