RE: [libreoffice-users] Re: Assessing ODF Conformance (Re: OASIS Standard ODF 1.2 Approved)

NoOp has carried out some interesting experiments by using an ODF Validator (below at the end).

This brings to mind a few observations.  They are intriguing for me because they illustrate
how tricky it is to assess conformance and also the pitfalls that lurk in assuming conformance
by default.  (As I said before, I think OpenOffice.org/LibreOffice are mostly conformant.
There is just no better calibration than that without some sort of serious account of any
deviations by design and solid testing for any deviations by mistake.

1. First, about the resiliency test documents at 
<http://tools.oasis-open.org/version-control/svn/oic/TestSuite/trunk/odf12/NameSpaceResilience/>

I was preoccupied with the variations of a single part of the package, the META-INF/manifest.xml
file that appears in each ODF package.  It did not occur to me to test the entire document in an
ODF Validator.  It is nevertheless gratifying that two of the three documents that have valid 
manifests are also valid according to the ODF Validator: 
<http://tools.odftoolkit.org/odfvalidator/>.

I should include the ODF Validator results along with the jing results.  But wait ...

2. It turns out that the ODF Validator rejects one of the test documents for invalid reasons.
That is, the validator doesn't handle XML namespaces properly itself.  It fails 03 *incorrectly*,
it fails 04 - 09 correctly.  So I shall add it in the row of ODF consumers rather than as an 
authority on the correct validation of the test documents.

3. ABOUT VALIDATORS AND SCHEMA CONFORMANCE
Schema validation is important because it is the fundamental syntactic check that the ODF 
document is well-formed.  It doesn't tell us that what an ODF-accepting application *does*
*with* *it* will be correct, and it doesn't tell us that the ODF-producing application 
is associating the correct syntax with the correct behavior on its part.  But it is definitely
a bar that an application is expected to jump over.

4. SILOS AND MONOCULTURES
It is quite possible that an application is handling an ODF feature incorrectly, but all 
appears to be well since the observed behavior does match what an user created using the
same software.  The breakdown in the use of ODF may not be apparent until interchange with
another product that supports the format and the mystery is revealed.  (This can also 
happen when round-tripping an export and reimport involving a different format than ODF,
but that is out of scope for this topic.)  There are some of those invisible deviations
detected in the validations that NoOp ran.

Now, when there is shared implementation, there is a monoculture problem:  The same, 
shall it be said, genetic disease, is inherited by all of the shared implementations, at
least until the defect is noticed in some other way.  At this point, it may actually need
to be concluded that the ODF Specification is the thing to fix unless it is simply too
unpalatable in a given case.

5. EXTENSIONS AND FOREIGN ELEMENTS

ODF does allow for extensions in a particular way.  It is by allowance of foreign elements.
ODF also allows certain characteristics of features to be implementation-defined (and 
documented) and implementation-dependent (and take your chances).  Only the occurrence of
foreign elements, attributes, and attribute values can be caught in an ODF Validator.
None of the documents that NoOp and I have tested give rise to any of those.

6. FINE DETAILS

NoOp's tests uncover interesting small problems in the way ODF is defined.  I invite scanning
over the reports that NoOp has included in his message, below, for the error messages 
related to
   fo:hyphenation-remain-char-count
   style:text-combine-start-char
   manifest:manifest version

 a. First, the fo:hyphenation-remain-char-count errors are errors.  The ODF Schema is 
violated.  Oddly, the problem for fo:hypenation-remain-char-count="0" is that XSL allows any 
number here, not just a positiveInteger, and the value used is by conversion to an
integer greater than "0".  But there's no question that the ODF Schema is violated.

 b. The style:text-combine-start-char="" is also wrong.  There must be exactly one
character in the attribute value.  One would have to look at the test document to know
what happened here.  The attribute is optional and it appears that it should have been
omitted if no character is specified.  This takes more work to analyze, and a document
having the defect is needed.

 c. The manifest:manifest lacking a version attribute is an interesting problem.
The Validator must be clever here, since the attribute is required only for ODF 1.2 
documents. However, the addition of the requirement was late in the development of
ODF 1.2 and it was probably misguided to not make it optional in 1.2 and maybe mandatory 
in ODF 1.3 documents.  (The attribute does not exist in ODF 1.0/1.1 at all.)
  So the change invalidates what 3.3.4 does, but 3.4.3 is all right in this respect.
I had something to do with this breakage by ODF hammer and I am embarrassed.  Worse yet, 
I am having a difficult time convincing the TC that it should be fixed.
  [My vote is to make it mandatory only in a manifest that requires that version in
order to be handled correctly.  Omission of the attribute alone should not be enough 
to make the manifest invalid if it is still a perfectly good ODF 1.0/1.1 manifest.
I get push-back from strict-conformance purists about this, though.]


-----Original Message-----
From: NoOp [mailto:glgxg@sbcglobal.net] 
Sent: Monday, October 03, 2011 11:20
To: users@global.libreoffice.org
Subject: [libreoffice-users] Re: Assessing ODF Conformance (Re: OASIS Standard ODF 1.2 Approved)

On 10/02/2011 08:55 PM, Dennis E. Hamilton wrote:
> Tom Davis remarks that he's noticed a couple of ODF-related bugs for
> LibreOffice and it is presumed that they have been fixed.  That's
> good to know.

FWIW:
https://bugs.freedesktop.org/show_bug.cgi?id=37390
[[Bug 37390] LibreOffice does not create valid ODF.]

I ran the file:
NameSpaceResilience-02-DefaultNS.odt
from
<http://tools.oasis-open.org/version-control/svn/oic/TestSuite/trunk/odf12/NameSpaceResilience/>
through:
http://tools.odftoolkit.org/odfvalidator/
and it passes.

I then opened the file in LO 3.4.3 (linux) using the default 1.2
(extended) and saved it as:
NameSpaceResilience-02-DefaultNS_Extended_343.odt
and ran it through the same tool. Result is:

This file is NOT valid

Result details:

> This file is NOT valid
>
> Result details:
>
> upload:///NameSpaceResilience-02-DefaultNS_Extended_343.odt/styles.xml[2,5299]:Error:attribute 
> "fo:hyphenation-remain-char-count" has a bad value: "0" does not satisfy the "positiveInteger" 
> type
> upload:///NameSpaceResilience-02-DefaultNS_Extended_343.odt/styles.xml[2,5886]:Error:attribute 
> "fo:hyphenation-remain-char-count" has a bad value: "0" does not satisfy the "positiveInteger" 
> type
> upload:///NameSpaceResilience-02-DefaultNS_Extended_343.odt:Info:Generator: LibreOffice/3.4$Linux 
> LibreOffice_project/340m1$Build-302

Turned off 'extended' and used only 1.2 and resaved as:
NameSpaceResilience-02-DefaultNS_NonExtended_343.odt
Reran the test:

> This file is NOT valid
>
> Result details:
>
> upload:///NameSpaceResilience-02-DefaultNS_NonExtended_343.odt/styles.xml[2,5249]:Error:attribute 
> "fo:hyphenation-remain-char-count" has a bad value: "0" does not satisfy the "positiveInteger" 
> type
> upload:///NameSpaceResilience-02-DefaultNS_NonExtended_343.odt/styles.xml[2,5836]:Error:attribute 
> "fo:hyphenation-remain-char-count" has a bad value: "0" does not satisfy the "positiveInteger" 
> type
> upload:///NameSpaceResilience-02-DefaultNS_NonExtended_343.odt:Info:Generator: 
> LibreOffice/3.4$Linux LibreOffice_project/340m1$Build-302

Did the same with LO 3.3.4:

3.3.4 1.2 Extended:

> Result for NameSpaceResilience-02-DefaultNS_Extended_334.odt
>
> This file is NOT valid
>
> Result details:
>
> upload:///NameSpaceResilience-02-DefaultNS_Extended_334.odt/META-INF/manifest.xml[2,88]:Error:element
>  "manifest:manifest" is missing "version" attribute
> upload:///NameSpaceResilience-02-DefaultNS_Extended_334.odt/styles.xml[2,5441]:Error:attribute 
> "style:text-combine-start-char" has a bad value: the length of the value is 0, but the required 
> length is 1.
> upload:///NameSpaceResilience-02-DefaultNS_Extended_334.odt/styles.xml[2,6028]:Error:attribute 
> "fo:hyphenation-remain-char-count" has a bad value: "0" does not satisfy the "positiveInteger" 
> type
> upload:///NameSpaceResilience-02-DefaultNS_Extended_334.odt:Info:Generator: LibreOffice/3.3$Linux 
> LibreOffice_project/330m19$Build-401

3.3.4 1.2 Non-extended:

> Result for NameSpaceResilience-02-DefaultNS_NonExtended_334.odt
>
> This file is NOT valid
>
> Result details:
>
> upload:///NameSpaceResilience-02-DefaultNS_NonExtended_334.odt/META-INF/manifest.xml[2,88]:Error:element
>  "manifest:manifest" is missing "version" attribute
> upload:///NameSpaceResilience-02-DefaultNS_NonExtended_334.odt/styles.xml[2,5391]:Error:attribute 
> "style:text-combine-start-char" has a bad value: the length of the value is 0, but the required 
> length is 1.
> upload:///NameSpaceResilience-02-DefaultNS_NonExtended_334.odt/styles.xml[2,5978]:Error:attribute 
> "fo:hyphenation-remain-char-count" has a bad value: "0" does not satisfy the "positiveInteger" 
> type
> upload:///NameSpaceResilience-02-DefaultNS_NonExtended_334.odt:Info:Generator: 
> LibreOffice/3.3$Linux LibreOffice_project/330m19$Build-401


...


-- 
For unsubscribe instructions e-mail to: users+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted


-- 
For unsubscribe instructions e-mail to: users+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted