OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Reason and example arguing for the use of an ODF (or XML) canonical form

I think the following suggestion would fall into one of the areas of overlap between the ODF TC and the proposed OIIC TC:

Require that a conformant document be saved only in XML canonical form.

Preferably, also define a canonical form specific to ODF (and then instead require saving to this form). This thread http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00537.html and elsewhere described some reasons to consider creating a canonical form for ODF beyond the existing standard XML canonical form.

Apart form facilitating testing and discussions of conformance, doing things like eliminating variations in whitespace (a property of XML canonical form) takes away one more weapon from vendors that want to thwart interoperability. Any monopolist would have incentives, born out by history, for wanting to prevent interoperability with their products. This obstacle to interoperability should not be ignored by the OIIC TC even if there is only so much that it can do for cases where vendors won't cooperate.

For those interested, I'd like to explain more carefully what I mean about abusing the flexibilities afforded by XML in order to thwart interop (eg, through abuse of whitespace allowed by XML in noncanonical form).

Before quoting from a recent email I sent, I want to again explain something so that I am not misunderstood. A monopoly position in a market is a position shared by a limited number of vendors. Today, in various markets directly related to ODF, a single player is currently recognized specifically before the law as being in a privileged position and having special laws apply exclusively to it. In what follows, I refer to that vendor indirectly. What I am referring to is the vendor in that monopoly position, whomever it may be to occupy that position at any given point in time if anyone. My reasoning about what a vendor in that position may or may not want, plan, or do is based on what I think is the most logical behavior to expect. Given that antitrust law is a bit general (does not apply to the software field specifically), many will legitimately disagree over the meaning of those laws as is the case over laws in general: if parties didn't disagree,
 there wouldn't be much of a need to ever have a protracted court case. Thus, it's possible for the to-be-described actions to become a part of a company's business strategy, even while the execs making those decisions think that they are violating no laws (or aren't sure). As a user and as a market participant, I want to hedge against this scenario. Having a monopolist around does pose a unique obstacle to interoperability because a single family of products does set a de facto standard that could easily be in contradiction to a de jure standard like ODF.

With this peak into my mind and remembering IANAL...

[Don't miss the following below: "Anyone not knowing the secret handshake will clobber the invisible cues..." as a reason to try and refer to canonical forms when making statements within the spec. This applies when a vendor has intentions to thwart interop AS WELL AS when the "secret handshake" is defined implicitly without ill-will on the part of anyone through decisions necessarily taken in coding up the apps (including bugs), especially when the spec leaves anything underspecified (as might be the case when canonical forms are not used).]

What is an XML tag? It's a cue. What is cued depends on what software is using up the CPU cycles when that XML tag is seen. Yes, anything stored on disk is a cue (XML is just a particularly constrained cue).

There is hope and effort by some to have the particular tag cue a well-defined behavior. That is the point of ODF, HTML, and others. The problem is that a typical tag can cue anything.

Let's talk about Monopolysoft. What would I want a tag to cue? Well, I can think of many things as a FOSS/Linux supporter. But if I were Monopolysoft, knowing my tools are closed source software and some monopolies, I would make sure to add cues that would result in arbitrary semantics arising from anywhere/everywhere on the entire platform (and exclusive to my closed platform). I'd do this in the name of a need to innovate.. a need to integrate.. etc.

You understand the value in reigning in the meaning of tags, I know, because you want to close loopholes in ODF. But some loopholes can't be closed. A particular app may behave more or less as expected, but other apps may derive different cues from the same tags. AND a platform is composed of many apps/processes and not just of the visible ODF consumer/producer. This last point is noteworthy when [a monopolist in a position to gain from thwarting competition] owns significant chunks of the puzzle.

Let's look at whitespace. Though inefficient, that is a loophole. I can encode instructions/cues by varying the amount of whitespace in key sections. Eg, after a picture tag, 2 spaces means "mysecretattribute=true" and 1 space means "mysecretattribute=false".

So ODF and CDRF and any XML-based standard are doomed from the start to prevent [monopoly position interop thwarting] just because XML has loopholes. For example, being XML, none of these constrain whitespace in many areas.

Now, among friends, it's good not to constrain whitespace, but when you are Monopolysoft, whitespace is but one of the many tools you will likely use in order to cue in your secret semantics. And it can be other parts of the platform that come to help here. Eg, whitespace may cue in a popup or a download or bring up help menus. This would be things that only Monopolysoft would know, that would add value and that would not work on "similar" files or "similar" platforms.

"Well there is nothing evil there," you say? Well, of course this is lockin. Imagine two "similar" files. One opens up an interactive movie theater experience and the other just opens up some plain document. The lock-in is that you can only get the big stuff when you save with MSO [MonopolySuiteOffice]. If you save with OO.o and open in MSO, the magic never got saved. Similarly, save in MSO but open in OO.o and the magic disappears into thin air. And both files are apparently identical and no test suite catches anything funky.

In fact, a ton of actual data might be stored on Monopolyware files not related to that document (created when you save via MSO on a Monopolyware Platform). The whitespace games I mentioned above simply cue in sections of these files and related processing.

In this way, the actual office file saved from MSO, whether binary, OOXML, or ODF, includes a ton of extra semantics, a bunch of INVISIBLE and UNDOCUMENTED tags. And these are tied in to Monopolyware at BOTH sides (reading and writing). This is illegal leveraging, but it won't be stopped in practice if people (authorities or consumers) don't get tough about it.

To recap, the lockin hooks and effects can be made subtle and virtually invisible. It can be made to be blamable on "bugs." It can be made to appear legal (eg, by exploiting the whitespace loophole in XML .. besides the extra holes in ODF and OOXML). But in all cases, the user experience will be negatively impacted when the Monopolyware Platform and apps are missing. [Eg, a "bug" may result in OO.o generated files getting resaved badly from MSO, while MSO created files get resaved well because of a funky whitespace "bug". Eg2, intentional acts can be made very difficult to find (see the PS at the end of this reply) and similarly result in corruption or special semantics only being included when Monopolyware is there for the whole "round-trip". ODF [perfection] will not solve the Monopolysoft lock-in round-trip problem.. except for limited circumstances for third parties that use Monopolyware to build their apps: Illegal tie-in.]

OK, let's look at an imaginary session on MSO. MSO will have movie theater options presented during document creation time. Some of these will be presented very subtly or rely on past uses on the platform and hence automatically be included in the document without user awareness. The user thinks this is just normal and doesn't realize that anything special is going into the session. Finally, they then have to deal with two very different experiences when they read back their session/file, depending on whether they reuse the Monopolyware Platform or not.

Through the invisible example of whitespace cues, round-tripping, no matter how much one tries to make it part of the standard by defining it aggressively, will fail for the case of: Monopolyware products + third party products not relying on special Monopolyware favors. Anyone not knowing the secret handshake will clobber the invisible cues. BTW, a third party can be rewarded without being told the secrets. Eg, if you use Monopolyware Vis Studio, then all the magic is done for you in the background.

The problem is that standardization of software has not and will not likely evolve in the forseeable future (if ever) to a point to tame Monopolysoft ambitions for lock-in and for the preservation of their monopolies.

... [The rest of the quote is less relevant to the canonicalization argument, but I wanted the clarifications stated to help avoid unnecessary misrepresentations.]

Note, that FOSS can also do movie theater productions. Don't infer that the movie thing is a "benefit" of going with Monopolysoft.. a special value add unique to the monopolist.. because it isn't exclusive to them by any means. I used that example since Monopolysoft will use the guise of a "document" standard in order to stick in all sorts of semantics that may exist on Linux but just not within "office documents."

Note, too, that FOSS can also obviously have app dependencies. My claim is that app dependencies from any practical standard is almost unavoidable (at least in the initial rounds of feature introduction before the competitors get serious in trying to quell the more significant bugs and feature disparities by looking at the reference source code), but with FOSS, you know what is going on and can adapt. With Monopolysoft, you can't know and can't adapt without their help (if you want to take that "partner" path and leave yourself at their mercy), and you can almost guarantee that the Monopolyware app dependencies will exist ..in droves.

I hope no innocent parties were offended. The monopoly situation is real, and it would be negligent not to take those unique obstacles into consideration.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]