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 scenario GET Params on URL POST Form params on URL or Body (x-www-form-urlencoded) XML in body (xml) PUT Form params on URL or Body (x-www-form-urlencoded) XML in body (xml) DELETE 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. Thoughts? Simon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
