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: Re: [oiic-formation-discuss] "Strictly conforming" is not related to "interoperable"

[I am resending this email since it's been a while and I haven't seen it appear on the list. Please disregard duplicates.]

--- On Mon, 6/16/08, robert_weir@us.ibm.com <robert_weir@us.ibm.com> wrote:

> From: robert_weir@us.ibm.com <robert_weir@us.ibm.com>
> Subject: Re: [oiic-formation-discuss] "Strictly conforming" is not related to "interoperable"
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Monday, June 16, 2008, 5:20 AM


> Strictly conforming disallows the extensions.  So it does reduce the range of variability.  But it doesn't eliminate it.  So I think there is a relationship there, but not one which in itself guarantees interoperability.

That email from a few days back was a tough piece for me to swallow (were I now to reread it, and even at times when I was writing it) without some amount of regurgitation or at the minimum some heartburn. One thing I like about math is that you basically have enough control over the (definitions of the) basic elements of an area of concern in order to be able to (in most cases) come out eventually with very convincing proofs about relationships.

With the analogies expressed in that email, C vs ODF, there is much that is not nailed down and well-defined (I alluded to the inability of me to map items nicely). I truly am not thinking now that interop is completely disconnected from conformance. Not having found a proof or explored that area carefully, I presented something like a conjecture (much rougher since it's a broken analogy). My thoughts on the conformance/interop relationship potentially change minute to minute because I've still mostly unexplored the region.

But at the time I wrote that I was moved a bit and was interested in the "conjecture" that these two are quite separate. I appreciated the perspective that interop requires a whole set of standards specifically for it. Certainly, it helped in understanding that in fact a good (for its purpose) strictly conforming definition/framework might end up saying nothing at all about any level of interoperability. In a sense the conforming clauses might define the elements of the game but not really define any interop-necessary rules. .. So I like the perspective, but am not alleging any definitive connection between these two (at least not this minute :-) ).

From the last batch of emails I wrote, certainly a suggestion is that it might be possible to adjust ODF or (more usefully) create a suitable profile X to arrive at well-defined interop rules. I'm still exploring.

>> An important concept is "allowed range of variability" that a standard allows implementations.

Taking the extensibility tool away from a document standard might even be argued to be an absolutely ridiculous notion if you at all intend to have the standard have long-lasting utility and be at all relevant to the usual markets. But it might be natural and very useful to have extremely well-defined *profiles* (or maybe even "interop profiles" if it turns out these two notions might in fact exist and be distinct).

While I intend to use open source office suite (plus other apps) that are the most flexible and extensible, I really see the value in having specific products or well-defined modes of operation within products, that completely define the range of allowable documents that it will handle. For a particular type of business, it would be great to have ODF profile X (which might include core ODF plus a few industry specific extensions) to completely restrict what a well-defined user community can do with the product. In real life, business rule coding (or some form of manual intervention) is frequently added to the pipeline to do things like to restrict the properties of the range of documents being generated and handled by the business. It would be really useful if it were possible to incorporate (declare) all of these definitions in something like ODF.

Using such an app (or a mode/version of the app), businesses and other users would save a lot of time and other resources. We love constraints, training wheels, when they match our needs precisely and when we value interop and those guides more than having any new feature (when that feature would imply an inability to use the old tools to achieve maximum interaction with the documents, if perhaps a little more clumsily). A good set of precise features and no more is what we sometimes really crave for accomplishing certain tasks, goals. The value add comes in the ease by which the documents would be created or used.

In short, it would be analogous to nailing down the internal interfaces and data types of a software "application", eg, the Linux kernel (a great idea perhaps, but only within limited contexts) even when a new data reorganization might more efficiently allow new features to be added. So with this data freeze, we'd still be allowed new ways of doing things, but they would have to map to the existing data structure (to achieve compat/interop vs. maximum efficiency). This does have utility within the real world: trading interop and future compat against maximum efficiency and some capabilities/features (eg, like trading the ability to "legally" carry on extra session or document state against certain new capabilities). Is there a large market? The answer to that will affect how much ground is made (eg, by the TC and others afterwards) moving in the direction of creating very tight profiles.

Something like an ODF/Public profile might be able to (at least ODF "legally") guarantee that a set of documents would be readable at all times (and writable) by all citizens and other consumers using ODF/Public certified products.

Today, we might achieve most of the same results through backend processing and (if through webform) javascript or similar tools in order to keep the boundaries of the interactions very narrow (but capable enough). When you order online, you go through a very limiting and well-defined interface. It's a simple and well-defined set of transactions you are after. Ditto for b2b transactions, webservices, etc, as well as many other interactions within the business itself. Could products meeting very well-defined (and very inextensible) profiles eliminate the need to have a lot more business code? Yes, to some extent, always.

More importantly, is it realistic to spend the resources to nail down specific sets of requirements that could not be changed over time? I would say affirmative for many scenarios. It's really about creating a well-defined interface at some point in time, because in practice, you could upgrade to a new profile in the future, but having the earlier well-defined profile would help interop (new products and profiles would leverage the old)..  This is done today narrowly when a vendor retains backwards compat in their new products. By codifying this aggressively (ie, aggressively to essentially fix the feature set of the product class at profile version x) we could possibly achieve interop across these individual vendors. We'd effectively link up product X version x with product Y version y with product Z version z, etc.

So there are many scenarios to want these limits and precision. A product "mode of operation" might be how you achieve these (hopefully guaranteeable) profiles within products in practice. In practice, we may also end up with many more loosely defined plugin projects to add the more specific needs (through source code extension and odf profile extensions) for particular user classes. This would mean that in practice, people would get 90% of their needs tied down aggressively and then get the remaining 10% through a combination of various channels they trust (eg, through open source fast changing "works in progress" as well as through ultra flexible home-grown proprietary code).


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