[Standards] Feedback on I/O Object Forms

Jakob Schroeter js at camaya.net
Fri Mar 16 12:08:47 UTC 2007

On Fri Mar 16 2007, Julian Kölle wrote:
> -------- Original-Nachricht --------
> Datum: Thu, 15 Mar 2007 18:02:25 -0700
> Von: "Chris Mullins" <chris.mullins at coversant.net>
> [...]
> > I can see defining some new field types:
> >
> > -          Base64 Binary Data
> > -          XML Data
> >
> > I understand the argument, "This is machine to machine communication,
> > and X-Data is meant for human-to-machine communication", but I think
> > it's flawed. X-Data (to me) seems to allow machine-to-machine with no
> > trouble.
> We thought about extending X-Data, too. However, as I pointed out and as
> you mentioned here, X-Data is for human usability. X-Data is just *one*
> data envelope, not *the* data envelope. As pointed out in XEP-0050, Ad-Hoc
> Commands is thought to support other Data Envelopes then X-Data - X-Data
> was just the example. As we said IO-Object Forms is for machine-to-machine
> communication. The current data types of X-Data are too limited for our
> needs. For example we want to transport CML documents or INSD documents or
> many other XML documents or even non xml data. You suggested to extend
> X-Data with new fields. Indeed this would work. However - as X-Data was
> thought to be used for human interoperability - we fear that we would break
> many existing X-Data client implementations due to an overload of possible
> complexity within the "extended" X-Data. How would a client X-Data GUI
> react on a XML object tree that contains the phylogenetic tree of a
> protein, including several protein sequences?

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.

> 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.

> 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.

In general, though, I'm just opposing to duplication of yet another protocol 
iff the same can be achieved with something existing.

Jakob (who doesn't have a clue about proteins ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070316/29754001/attachment.sig>

More information about the Standards mailing list