[Standards] Feedback on I/O Object Forms

aliban at gmx.net aliban at gmx.net
Fri Mar 16 17:52:35 UTC 2007


Chris Mullins schrieb:
> "Julian Kölle" Wrote:
>   
>> We thought about extending X-Data, too. However, 
>> as I pointed out and as you mentioned here, 
>> X-Data is for human usability. 
>>     
>
> I don't agree with that - I use X-Data all over the place for machine-to-machine communication.
>
> The biggest plus (to me) for using X-Data is the HUGE amount of support it already has in existing SDK's. For example the SDK with which I'm most familiar is the SoapBox Framework - we've got thousands of lines of code that operate on these forms and make them easy to use. Converting an initial form to a Submit form is all done, as are all the checks for things like required fields. Yes, there are GUI tools there too, but there's no need to use them. 
>
> Adding a new field to X-Data is way less work than creating a new Data-Forms-Like infrastructure. 
Yet another disadvantage of X-Data is that it does *not* decouple 
implementation from contract. Basic Service thinking these days 
says/wants this however. Our proposal defines a mechanism to get the 
function's Schemata separate from function execution.

See http://www.xmpp.org/extensions/inbox/io-object-forms.html#usecases
Section 4.3

The definitions of  IO-Object Forms are reduced to the minimum of 
requirements that are required for a function execution. On the other 
hand it is extremely flexible and allows everything a function execution 
might need.


See the following basic example of a function that applies to any remote 
or local function execution (API) (example based on Java or c) :

myObjectA theFunction(myObjectB) {
...
return new myObjectA(...);
}

this would be rendered in IO-Object Forms to:

<x xmlns='http://xmpp.org/protocol/io-object-form' type='form'>
  <in>
  ...XML representation of myObjectB...
  </in>
  <out>
  ...XML representation of myObjectA...
  </out>
</x>

I can not imagine it is that reduced in the X-Data Form. Implementation of this IO-Object Form is much more easy, in example you would not have to implement XEP-0122: Data Forms Validation (yet another XEP) to be type save - and this would be required for a stable SOA framework!



Best regards,
Edrin





More information about the Standards mailing list