Re: [oiic-formation-discuss] Interoperability versus Conformity

["Dave Pawson" <dave.pawson@gmail.com>]

2008/6/8  <robert_weir@us.ibm.com>:
>
> "Dave Pawson" <dave.pawson@gmail.com>

>> The relationship between conformity and interop has me confused.
>> I don't understand that.
>>
>
> Excellent point.  Let me state my interpretation.  And anyone let me know if
> they think this contradicts how they think of the terms.
>
> Conformity is the relationship between a technological artifact and the
> standard or standards that defines that technology.  So in our present case,
> conformity is the relationship between an ODF document, or an application
> that produces or consumers an ODF document, and the ODF standard.  The
> artifact is conformant with the standard when it implements all required
> provisions of the standard, and implements none of the prohibited provisions
> of the standard.

A nuance there I think we need to clarify.

an ODF document, or an application
that produces or consumers an ODF document,

Which? IMHO ODF specifies what a document instance should be/do.
It says nothing about producers or consumers?
Which are we testing.

Another refinement Rob. "A" Document? I guess we could produce a document
that minimally is valid to one part of the standard.

How do we say that (a suite of) documents from vendor X complies
with all the aspects of the standard that it uses/should be compliant with?
See the point? Vendor X may only implement a word processor.
Vendor Y implements all 3. We need to address this 'scope' issue?






>
> Conformity can be stated as black or white :  "Application X conforms,
> Document Y does not conform" or as partial conformance, "Application Z
> conforms to parts 1 2 and 3, except for Part 3, clause 26 and 29."

And, possible, Test groups 123-148 not run, hence untested.
(E.g. where a vendor doesn't implement a presentation app)


>
> Interoperability, on the other hand, is the relationship between two or more
> technological artifacts that implement the same protocol or protocols.  I
> can't give you a crisp black and white definition here.  But I can suggest
> some analogies.

<grin/> Just what has Rob swallowed!
"technological artifacts that implement the same protocol"
Agreed we need the terms for a spec, I'd prefer plain English for this group.

For our case, I'm interpreting this as 'Two word processor instances created
by different vendors'. Is that right?


>
> First, consider the C/C++ programming languages.  Both define formal
> provisions, and a compiler implementation, or a program file, could be
> tested as to whether it conforms to the underlying programming language
> standards.  However, this does not guarantee that two conformant C++
> compilers will create programs that yield the same runtime results.  This is
> because the C/C++ standards have items that are undefined and
> implementation-defined, like the size of an integer, or the sign of of a
> character, etc.  This is well-known to practitioners -- they know where the
> bodies are buried -- and there are a variety of practices which they know to
> institute if they want to create interoperable C/C++ code (or portable code
> as it is more often termed in this space).

Scary but understood. Thanks.


>
> Further, a more mature expression of these interoperability constraints (and
> that is what they really are -- additional constraints beyond the C/C++
> standards)can be written up in detail and agreed to by a set of vendors,
> becoming a standard that defines conformance of "portable C/C++" within a
> particular domain.  For example, Embedded C++ took that route, as a proper
> subset of ISO C++.  PDF/A did that as well, a constrained subset of PDF to
> increase interoperability in a particular domain.

No, you've lost me. Is this the two C++ compilers *without* the bodies
I.e. the subsets that produce identical results, or the 'list of bodies'


>
> So "interoperability" in the large is not something we'd just want to go out
> and start testing.  But we could define, for example, a proper subset of ODF
> for browser-based implementations, which contained only rendering primitives
> that could be losslessly mapped to the HTML/CSS2 model.  I could also
> imagine a profile of ODF for desktop use.

Wow. This is miles different from my own assumptions.
This sounds like

"The subset of the Word processor parts of the standard
that should be common between any two implementations"

Is that right? Especially the 'should be', i.e. we go hunting
the mandatory bits, then move out towards the 'hard to spec'
bits, determining what is a reasonable stop point?
E.g. Omit  pixel perfect visual output of an example line of text?

I do like the idea of profiles though.
The fluffy definition might be "The parts of the standard that
a  user would reasonably expect to produce identical output"
in profile X for application Y. "




>
> But I don't think we need to go that far initially.  We would make progress
> even with a check list of ODF features, set out in a table, and some simple
> tests cases that allowed an implementation to verify whether or not the
> features are even implemented.  Even doing this much would raise awareness
> of missing functionality, and when that is addressed interoperability
> increases.

A long slog, but doable. It would highlight weaknesses in the standard too.
The other key aspect would be an inter-dependence table?
This feature depends on that feature|para|clause whatever.
I see this as the pre-conditions for a test etc.
Equally I can't test this feature unless I have passed this list
of tests.



>
> Note also something unintuitive -- a high degree of interoperability is
> possible even without conformity.  I know this may sound like sacrilege, but
> a look at the web itself, where only a small fraction of web pages are valid
> HTML or XHTML.


Yes, I can see that :-)

Thanks Rob. Enlightening.


regards


-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk