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
- From: robert_weir@us.ibm.com
- To: oiic-formation-discuss@lists.oasis-open.org
- Date: Fri, 27 Jun 2008 11:25:45 -0400
"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 http://lists.dsdl.org/dsdl-comment/2008-06/0043.html
And please see further in that thread when Murata-san
admits he was mistaken:
http://lists.dsdl.org/dsdl-comment/2008-06/0053.html
-Rob
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]