Interoperability testing

["Daniel Greenwood" <dang@mit.edu>]

John,

Interoperability testing was part of the finalization requirements for old
LegalXML, Inc. standards from the start.  I seem to recal it is also part of
final OASIS standards, but I am not sure.  Need to check the rules again (or
maybe someone can pipe in here).

Thanks,
 - Dan

----- Original Message -----
From: "John McClure" <jmcclure@hypergrove.com>
To: "Daniel Greenwood" <dang@mit.edu>; "'Legalxml-Econtracts'"
<legalxml-econtracts@lists.oasis-open.org>
Sent: Wednesday, April 23, 2003 3:27 PM
Subject: RE: [legalxml-econtracts] Display/Presentation Agenda Item:
Proposed Wording Second Draft


> >...  On the other hand, if this requirement is
> >accepted and inside the scope, then implementation of our final
> >specification(s) would need to reliably result in identical display
between
> >the multiple parties to the contract.  One of the implications is that
any
> >interoperability testing that we might need before finalization would
> >necessarily have to include successful demonstration of this feature.
>
> I am concerned that this statement will lead us to a basic
misunderstanding of
> what our work product is supposed to be. We are creating standards for a
data
> stream that is exchanged between browsers; we're not creating
applications! Our
> work fits into the matrix of datastream standards being defined by the W3C
and
> others; if there is a feature that we functionally need, and it is
supplied by
> the machinery of CSS2, then we should not, we must not, re-implement that
> feature. This is an operating assumption we must make, REGARDLESS of
whether the
> feature is presently or correctly implemented by any of the browser
> manufacturers.
>
> In other words, we should ASSUME that implementations have available
> fully-conforming CSS2 browsers of HTML files. And, if necssary, we should
ASSUME
> that implementations have available fully-conforming XSL-T transform
engines.
>
> Think of the result if LegalXML re-specifies functionality already present
in
> other W3C standards which one would reasonably expect implementers of our
> standard already to be using, or expecting to use, in their
implementations:
> LegalXML would then be requiring implementers to implement functionality
that is
> SUPPOSED to be in conforming browsers. That would yield a complete mess if
every
> standards group did that!
>
> This is first time I have heard about "interoperability" testing.
> Interoperability is an APPLICATION concern -- this is not a concern of a
> standards group. All we're doing is specifying the format of a datastream,
for
> crying out loud! Again, I am concerned that this statement surpasses by
far the
> proper scope of this effort to standard the layout and format of a
datastream.
>
> So, here's my suggestion for the Second Draft, if that's what people want,
> instead of the First Draft -- both the First and Second Drafts are
functionally
> equivalent to me.
>
> [Second Draft amendedBy='JMc'] Yes or No: Subject to certain assumptions
about a
> user's operating environment, the final eContracts specification will
encompass
> and directly support the final, conclusive displayed version of a contract
that
> is agreed by the parties. [/Second Draft]
>
>
>
>