[Standards] Re: Feedback on I/O Object Forms
egon.willighagen at gmail.com
Sat Mar 17 10:58:57 UTC 2007
Jakob Schroeter wrote:
> I guess it would just ignore those parts it doesn't understand. But I'm
> not sure why this matters. Since this is a special application you would
> obviously use a specialized client for optimal end-user experience, if you
> want to involve end users at all. An Adhoc Commands-capable off-the-shelf
> client wouldn't be able to handle IO Object Forms either.
If I understand you correctly, you propose to just add a layer on top X-Data
to deal with a subset of X-Data being XML-based data. And just throw errors
when the lower X-Data layer does not contain XML data?
>> Someone who codes a script
>> against such a services would know how to handle the return (documented)
>> objects. A dynamically generated GUI wont be able to handle. it.
> Of course, re-using Data Forms doesn't mean you have to re-use existing
> client implementations, or any GUI at all.
One of the problems with SOAP is that all implementations are mutually
incompatible, because each of them only works with part of the
Which is why I prefer to have a separate specific format, which is well
defined, small (KISS), so that an implementation of the full specification
I also do not understand why it would be useful to have machine-to-human
interaction libraries work with big blobs of XML data (MBs is no
exception). That is bound to give trouble in existing libraries, I would
>> We think that it makes sense to define an input-output namespace, where
>> we can put arbitrary XML objects in, for being handled by the
>> programmer/script developer and not by a client mechanism that renders a
>> GUI around it (they could hold binary data too, if needed). A service may
>> support even both namespaces, X-Data and IO-Object Forms. One that may be
>> used by a Human directly by rendering a GUI around X-Data, the other to
>> be handled as a complex XML DOM by a programmer/script developer.
> And you could use one representation for both use cases. You would have to
> base64() binary data anyway to get it through XMPP.
Not having a big track in the whole XMPP specifications myself, I do not
understand this argument.
> In general, though, I'm just opposing to duplication of yet another
> protocol iff the same can be achieved with something existing.
It is not duplication: different field of application, different
I could argue that the X-Data concept could be achieved without the X-Data
specification too, just putting some restrictions on the clients that deal
with that use of XMPP itself. Hell, even XMPP can be dropped then, because
we can achieve the same with other protocols.
What I think is more important, is that we have clean, easy to use standards
which do what we want it to do. I do not think that involves tweaking
things for which they were not really set up.
Sorry for sounding a bit blunt here (had a few bad days), but I am opposing
the idea that a protocol is useless if you can hack and tweak other things
to get the same result.
e.willighagen at science.ru.nl
Cologne University Bioinformatics Center (CUBIC)
More information about the Standards