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:[email protected]] Sent: Monday, October 03, 2011 11:20 To: [email protected] 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: [email protected] 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: [email protected] 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
