Subject: RE: [oiic-formation-discuss] What is interoperability anyway / really?
Shawn, 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 / really? From: Shawn <firstname.lastname@example.org> Date: Sun, June 08, 2008 3:17 pm To: Cc: email@example.com 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.. :) Shawn 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: > firstname.lastname@example.org For additional > commands, e-mail: email@example.com --------------------------------------------------------------------- To unsubscribe, e-mail: firstname.lastname@example.org For additional commands, e-mail: email@example.com