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] What is interoperability anyway / really?


I think what you say here tallies well with Rob's "capabilities table" and the 3 levels segmentation in CAM.

Notice that your Philips example when you analyse it is calling out for a basic set of operationally compatable capablities (abilities to insert and extract a screw with any given head size, successfully without ruining the screwhead itself and with average torque needed).
Similarly for ODF - you can create a test case with expected outcomes and content capabilities - without having to exactly specify minutae of details - or expect exact binary equivalence.

This was my point earlier - that its easier to have a somewhat looser definition that allows a wider set of implementations to provide a robust base level of functions - rather than expect slavish compliance to a rigid machine level binary specification.

Thanks, DW

-------- Original Message --------
Subject: Re: [oiic-formation-discuss] What is interoperability anyway /
From: Shawn <sgrover@open2space.com>
Date: Sun, June 08, 2008 3:17 pm
Cc: oiic-formation-discuss@lists.oasis-open.org

New to the list, so I apologize if I'm a little off in my understandings...

The best example of Interoperability I can think of is a screw driver. 
A phillips (aka star) screw driver is a "standard". It has many 
manufacturers - MasterCraft, Stanely, etc. I can easily substitute any 
manufacturer's phillips screwdriver, for use with any phillips headed 
screw, and expect the same usage method, and same results. (yes, I 
conveniently ignored the size of the screw/screwdriver here)

Applying this idea to software, particularly where documents/data is 
concerned. I would expect that I can use any manufacturer's/vendor's 
tool to apply to my problem (creating/saving a document), and get the 
same results. I would expect to be able to swap out the tool used at 
any time, with no hassles. Simply because the definition of the 
data/document is well enough that every manufacturer knows what is 
expected when creating or reading those documents. This also means I 
can easily move my document around the Internet and various 
organizations I deal with, as the (well defined) document becomes the 
driving force for the tool, not the otherway around.

To achieve true interoperability, we need an unbiased definition of the 
document. To me that means putting on my "document definition" hat and 
asking what is right for this project, and not letting any outside 
influences affect that.

My thoughts. And I'll return to lurking now.. :)


David RR Webber (XML) wrote:
> Dave,
> Guess we need to broach this topic some too.
> For me interoperability is about people being able to predictably 
> exchange documents - and publish clear instructions on rules / handling 
> / content models including contextual templates and patterns that are 
> intended / expected.
> Sadly we have a chunk of folks out there that believe publishing an XSD 
> and then enforcing validation there of is how you achieve interoperability.
> They are angry and confused when things pass their XSD and proceed to 
> trash their backend applications - or frustrated when people construct 
> what appear to be reasonable content from human perspective - but the 
> XSD rejects as invalid for some arcane reason. Then of course the final 
> straw is wierd content created automatically by tooling software that 
> passes the XSD but is a nightmare to process and contains 3x the amount 
> of markup that sane people would ever want in there!
> The problem put simply is that XSD is non-deterministic - and was never 
> meant to be deterministic.
> So in our case - scripting tools like CAM add context - and ability to 
> assert deterministic rules that make predictable outcomes possible. A 
> "filter" in effect - that can tell you if the content will be acceptable 
> and make sense.
> But CAM is designed for business transaction exchanges - not documents. 
> However the principles are the same - just that the set of "smart" 
> functions need to be adapted to document application needs - such as 
> page counts and section content / page headers / footers, signatures, et 
> al - which are not part of the lexicon of CAM.
> So - overall seems to me for interoperability - you need the same 
> ability as CAM brings to produce open standard sharable rule sets and 
> patterns that can be verified, documented and will check instances 
> conform to them - but with a document lexicon of functions....
> Thanks, DW
> --------------------------------------------------------------------- To 
> unsubscribe, e-mail: 
> oiic-formation-discuss-unsubscribe@lists.oasis-open.org For additional 
> commands, e-mail: oiic-formation-discuss-help@lists.oasis-open.org

To unsubscribe, e-mail: oiic-formation-discuss-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: oiic-formation-discuss-help@lists.oasis-open.org

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