Comments on: Interoperability the ELIZA way http://www.robweir.com/blog/2008/02/interoperability-eliza-way.html Thinking the unthinkable, pondering the imponderable, effing the ineffable and scruting the inscrutable Wed, 10 Mar 2010 01:51:22 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: John Cowan http://www.robweir.com/blog/2008/02/interoperability-eliza-way.html#comment-1534 John Cowan Sun, 24 Feb 2008 22:09:00 +0000 http://www.robweir.com/blog/2008/02/interoperability-the-eliza-way.html#comment-1534 You can pit Eliza and Zippy the Pinhead against each other by firing up GNU Emacs and typing "meta-x psychoanalyze-pinhead". Be quick with the Ctrl+G, though, because it's an infinite loop.<br/><br/>One of the silliest things you can do with a computer. You can pit Eliza and Zippy the Pinhead against each other by firing up GNU Emacs and typing “meta-x psychoanalyze-pinhead”. Be quick with the Ctrl+G, though, because it’s an infinite loop.

One of the silliest things you can do with a computer.

]]> By: Anonymous http://www.robweir.com/blog/2008/02/interoperability-eliza-way.html#comment-1522 Anonymous Tue, 19 Feb 2008 04:21:00 +0000 http://www.robweir.com/blog/2008/02/interoperability-the-eliza-way.html#comment-1522 I guess it depends on whether the 'store and forward' data is content (as in OOXML or ODF element, OLE object or formatting tags) that are not understood during the round-trip but are retained in the document anyway vs things like 'page size' or 'margin settings' or 'default font' that may differ between KOffice and OpenOffice.org, yet seem safe to store-and-forward if the two applications have valid reasons for having different defaults or if the ODF spec does not have these tags defined as they only impact the source application.<br/><br/>Likewise, it seems reasonable to allow KOffice to flag any spreadsheet cells that have annotations even though OpenOffice.org does not support those tags and even though the ODF does not (yet) support the tags. That is either allow the use of these tags as vendor-specific or at least not deny them the ability to extend, as long as efforts are made to eventually incorporate these extensions back into the main specification. - And as long as these tags are not crucial to the use of the spreadsheet. I would hope that as time goes on, useful and popular annotation tags would be proposed and accepted back into the ODF standard so they can be removed from the KOffice-specific settings in future ODF specification revisions.<br/><br/>This allows for incentive to add features to ODF-compliant applications that - if popular, can become part of the overall standard.<br/><br/>Just my two cents...<br/><br/>--Ed I guess it depends on whether the ’store and forward’ data is content (as in OOXML or ODF element, OLE object or formatting tags) that are not understood during the round-trip but are retained in the document anyway vs things like ‘page size’ or ‘margin settings’ or ‘default font’ that may differ between KOffice and OpenOffice.org, yet seem safe to store-and-forward if the two applications have valid reasons for having different defaults or if the ODF spec does not have these tags defined as they only impact the source application.

Likewise, it seems reasonable to allow KOffice to flag any spreadsheet cells that have annotations even though OpenOffice.org does not support those tags and even though the ODF does not (yet) support the tags. That is either allow the use of these tags as vendor-specific or at least not deny them the ability to extend, as long as efforts are made to eventually incorporate these extensions back into the main specification. – And as long as these tags are not crucial to the use of the spreadsheet. I would hope that as time goes on, useful and popular annotation tags would be proposed and accepted back into the ODF standard so they can be removed from the KOffice-specific settings in future ODF specification revisions.

This allows for incentive to add features to ODF-compliant applications that – if popular, can become part of the overall standard.

Just my two cents…

–Ed

]]> By: Chris Ward http://www.robweir.com/blog/2008/02/interoperability-eliza-way.html#comment-1521 Chris Ward Tue, 19 Feb 2008 00:42:00 +0000 http://www.robweir.com/blog/2008/02/interoperability-the-eliza-way.html#comment-1521 'Hints' are worse than that; they can mislead.<br/><br/>If the 'other side' interprets the hints, rather than the docuement, then a 'man-in-the-middle' can alter the hints, and you can end up with opposite meanings depending on which application you use.<br/><br/>I am reminded of the machine translator which read "Out of sight, out of mind" and (after round-trip to Japanese and back) came up with "Invisible Idiot".<br/><br/>We shall see. This proposed standard is a "Presidential Election", or a "Superbowl". One side will win and the other will lose. <br/><br/>Either way, OOXML will not be a consensus standard. It will be a 'single vendor and their business partners' product specification. Nothing wrong with that; but it's the nature of the world that not everybody can be a Microsoft business partner. There have to be customers, and competitors, as well. ‘Hints’ are worse than that; they can mislead.

If the ‘other side’ interprets the hints, rather than the docuement, then a ‘man-in-the-middle’ can alter the hints, and you can end up with opposite meanings depending on which application you use.

I am reminded of the machine translator which read “Out of sight, out of mind” and (after round-trip to Japanese and back) came up with “Invisible Idiot”.

We shall see. This proposed standard is a “Presidential Election”, or a “Superbowl”. One side will win and the other will lose.

Either way, OOXML will not be a consensus standard. It will be a ’single vendor and their business partners’ product specification. Nothing wrong with that; but it’s the nature of the world that not everybody can be a Microsoft business partner. There have to be customers, and competitors, as well.

]]>