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] Proposed Use case -- Interoperability invertical and horizontal ODF markets

"Dave Pawson" <dave.pawson@gmail.com> wrote on 06/27/2008 10:38:58 AM:

> 2008/6/27  <robert_weir@us.ibm.com>:
> > In any case, this could be tested in a conformance test and a information
> > message emitted on whether or not the application preserves foreign elements
> > and attributes.
> How, when the standard doesn't define foreign?
> Nor if odf elements are to be processed if within 'foreign' elements?

"Foreign" is defined in section 1.5, first paragraph.

>  Since this provision is not expressed as a recommendation
> > or requirement, we have no basis (in the standard) for issuing a warning or
> > an error.
> I.e. it is untestable. 14% of section 1 is untestable in a like manner.

It is not untestable.  Testability is a matter of whether something is stated with enough precision that one can craft a useful test case.  This can be done for any provision of the standard, including requirements, recommendations, statements of permissible action and statements of possibility or capability.  These are all provisions, are all normative and, when well-written, are all testable.  What we cannot do is hold failure of a test case against conformance of an application unless that test case is traceable to a mandatory requirement of the standard.

For example, an attribute or element with the namepace prefix "foo", where "foo" is associated with the namespace "urn:bar" is a foreign element or attribute according to the standard.  There is not the least bit of ambiguity in that.  So a test case could be crafted with such foreign attributes or elements and an application tested to see whether or not it preserved it.

I'm not denying that there is some fuzziness in the standard, but there is also a lot that is not fuzzy, and we should concentrate on that.  We can accomplish a lot to improve interoperability without engaging in language lawyer mind games.  Implementations today are not making subtle errors.  So a disproportionate emphasis on minutia accomplishes little.  If an implementation fails to preserve foreign attributes and elements today, it does so everywhere and all the time.  There is no application out there that fails this test case in a subtle way.

> See also

And please see further in that thread when Murata-san admits he was mistaken:



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