Re: [oiic-formation-discuss] "Strictly conforming" is not related to "interoperable"

[jose lorenzo <hozelda@yahoo.com>]

--- On Sat, 6/14/08, Dave Pawson <dave.pawson@gmail.com> wrote:

> From: Dave Pawson <dave.pawson@gmail.com>
> Subject: Re: [oiic-formation-discuss] "Strictly conforming" is not related to "interoperable"
> To: hozelda@yahoo.com
> Cc: oiic-formation-discuss@lists.oasis-open.org
> Date: Saturday, June 14, 2008, 4:28 PM
> 2008/6/14 jose lorenzo <hozelda@yahoo.com>:
> 
> > Contrast this to ODF, where specifically extensions
> are defined as the addition of distinctly named element
> nodes, and as long as these use (are qualified with) a
> different namespace than those used in the standard, you
> can still maintain "conformance".
> 
> 
> Which is a facet of XML - not ODF or ooxml.

No, this is a part of ODF (if I understood it correctly). ODF can choose to say that adding any foreign element breaks conformance *with ODF*. It would be wrong for ODF to say that adding foreign elements would break conformance with XML. I'm not sure why ODF would ever say that though since the conformance clause within the ODF std is about nothing more and nothing less than conformance with ODF itself (though ODF documents are a subset of XML documents, fwiw).

What is also true and is related to XML is that you can always add so-called ODF foreign elements to an ODF document (according to current ODF standard) and still be legal XML.. but you would not be legal ODF in that case if ODF wanted things to be that way. If ODF was in fact changed to disallow foreign elements, then it would still be true that every ODF document would be an XML document. Only now, you'd have a few documents that would be XML documents, as always, and used to be ODF documents but no longer are ODF documents.

If I dump a game from my "Exclusive Set of Games I Own" then that game doesn't stop being a game. I never said I was dumping it from being a game. I said I was dumping it from being an "Exclusive Set of Games I Own".

ODF v. x has points a and b.
XML has a, b, and c
If ODF v. y now only includes point a, you have not said anything inconsistent with the still true statement that XML has a, b, and c. In other words, if you change that wording on ODF to lose "a", you don't violate XML. Ie, b is still XML; a is still XML; and c is still XML. I didn't violate anything outside of ODF (or at least not XML conformance since every remaining member of ODF is still an XML document.. assuming I understand the link between XML and ODF).

Put one more way, all members of ODF are members of XML though there are members of XML not in ODF. If you change ODF to kick out some members that were in ODF in the past, then you have reduced the total number of members of ODF, but XML still has all those members.

Put yet another way, XML has a bunch of members. Say n number of them are in ODF today. Changing ODF so that it now has n-1 members just means that there is now one more member of XML that is not in ODF than was the case before the change. There is no violation here.

If you still don't see this, reply..

OK. liken XML to "all cats in the world". Liken ODF to "all cats that belong to me". Notice that all cats that belong to me are cats in the world [ODF is a subset of XML]. If I change [ODF] so that now I own one fewer cat, I have not violated [XML] the set of cats in the world, meaning that all cats I now own [ODF] are still a part of [XML] all cats in the world and all cats that were a part of the world before [ODF as well as XML-ODF] are still a part of the world, including the one cat that used to be a cat of mine but now isn't. The only thing changed is that one cat now is not my cat, but this is OK because I changed ODF on purpose to have a more narrow definition.

Of course, changing ODF as such would mean that then some existing ODF version n documents would seize to be "conformant" with the then new version n+1 ODF, but that is a different issue and has nothing to do with XML. That would be an ODF break compat with earlier versions issue.

It's tough to draw out sets and logic carefully through email and without interaction from the other person to know if they misunderstood something.. or if I misunderstood you [so the repetition is to cover as much ground I can through one round trip of emails].

> Some may not think this should be part of ODF, others do.

???

> It is a fact and something that exists. Like adding
> libraries to the C standard.
> You may not like it, others will like it.

Adding something to the standard makes it standard. The point is about a vendor NOT adding their secret sauces to the standard.

> embrace and extend? It is a possibility we have to live
> with.

It's beyond a mere likelihood, as I see it. In fact, even people that want to interoperate have a difficult time doing so (because of bugs and other flaws if nothing else) and, really, can effectively only interoperate by viewing each others' source code (at least in the worst case scenario).

Notice that Linux works because everyone can potentially see everyone else's source code.

Notice that Microsoft products generally work with each other. It's because everyone in Redmond potentially can see the source code of everyone else also working on related products.

Ditto for all other companies, in general, when referring to internal products.

So to get back on track, without open source, it's very difficult to interoperate very well even when all parties want to. [Testing can help smooth things over ASSUMING people will WANT to interoperate. If you don't want to interoperate, it won't happen. It's much easyeasier to be sloppy, go home early, not cross the t's, and make more money as other products fail to gain traction in the market place saturated with documents that do the interesting stuff in your secret "buggy" "sloppy" "go home early" language. What a solid standard and great tests can do with those that don't want to interoperate is to identify them so that their "certification" can be revoked.]

My point is all about the fact that at least one party does not want to interoperate, so I would say that we are talking about a lot more than a mere "possibility". A failure to realize interoperability is about as guaranteed of a statement as you can make about anything in the future [assuming "interop" is not defined extremely weakly]. There will be issues and effectively extensions of the standard (again, if only because of bugs, causing some docs that will only work with your own app.. but here also because of tremendous losses to be incurred by Microsoft).

All will not be in vain however if we can clearly root out implementations (apps) that are failing frequently and in many ways. In this case, the buy side of the market knows whom to avoid.

Well, if "interop" is very weakly defined.. if there are few useful things required out of "interoperability", then perhaps it would hardly hurt the dominant vendor to try and go along.. in fact, originally, I did not think I would hang around the mailing list very much at all thinking that, later on in almost any case, there would be arguments by Microsoft after complaints to antitrust authorities: "each of the things we implement away from the standard has at least one little bitty old item that makes it *more valuable* than what the standard provides for; hence we extended ODF in order to provide our customers with a feature outside the standard."

I want to make sure people are aware of this because there is still time to possibly find a way to fix the dilemma.

[Recap] My main concern are several:
-- hopefully not let those that don't interoperate get a free and undeserved certificate/passing grade.
-- perhaps a fairly good strong standard can be made to at least make it known if someone has violated it after the fact (and catching submarine feature implementations).
-- finally, if possible, seek preventive measures by trying to have tests that will find as many violating cases as possible (and this means you want to avoid having vendors code to the tests since then the actual violations will be hidden).

[The first two points are actually related I think, but I was thinking of levels of strength: (a): weak statements but no free passes for anyone -- interop is out of scope; (b): strong but mostly untestable; (c) strong and testable. I think strong testing (assuming a strongly designed framework exists) will ultimately be done by outside open source community watch dogs regardless of what OASIS handles officially.]

With repeated app conformance failures during legitimate and open tests, customers looking for interoperability will lose faith in these vendors. However, since you can code your product to pass or excel in known tests (even more known if the source is available), I think it will take constant effort to keep the tests up to date to provide the pressure on vendors to actually try and follow the standard instead of coding in the select special paths that pass the anticipated tests.

*****

The standard can be bypassed submarine like through the payload of the ODF elements (eg, text:p). Thus, I think the standard would have to find tough wording so that at least in some tight profile, it could guarantee/expect/demand (for conformance) that the features of that profile could not be implemented except as defined by that profile explicitly.

In this case, it would be understood that there could be no extension features of any kind, so any document not looking the same in all apps means a bug somewhere among them.

[Anyway, you still have privacy issues and data gathering through payload hiding. Who knows what is being encoded within documents when it uses a secret language within payload that allows for that possibility. This is an issue not of direct concern to this goals of this gathering, but I always like to put as much on the table to have perspective in designing goals and such.]