Checklist for ODF 1.4

[svanteschubert]

Postponed to ODF 1.4:

• 1 - Part 1,3,4: Removing accidental bookmarks not defined as allowed cross-references
• 2 - Part 1-4: Replacing non-mnemonic TOC references with generated ones based on XML node names"
• 3 - Part 2: Check for ISO Keywords styling: “should”, “should not”, “may” and “need not” - replace "must"
• 4 - Part 1,3,4: Check for ISO Keywords styling: 'shall', 'shall not', 'should', 'should not', 'may' and 'need not' - replace 'must'
• 5 - Part 1-4: Adding 'Normative'/'Informative' parent template styles beyond "Normal" specification root style
• 6 - Part 3: Default Value XSLT enhancement for conditional default values
• 7 - all Part: Exchange release ID, e.g. from "community specification draft 03" to "community specification 02", the "CSD03" was exchanged to "CS02" and the previous version "CS01" was exchanged to "CSD03". But there is also the Title (above the links) and a mentioning at the bottom of page 1 of the current version, e.g. "Draft 03", which manually has to be adopted! Sometimes there is metadata in content.xml user-defined attributes, which should be normalized and updates should be automated.
• 8 - Part 3 shows a HTML XSL problem with a dot after "as-character" anchored image, see details Part3: Exchanging 4x draw:circle with SVG images generating new HTML #33

[franciscave]

In ODF 1.3 CS02 Part Schema, section 19.381 is blank in the .odt and .pdf versions and is missing entirely in the .html version.

I believe that this was the result of deleting the attribute 'office:process-content'. Should the blank heading remain, or should it be removed and leave a gap in the numbering? I suspect that neither of these is ideal.

[franciscave]

Need to check for data types and values that are in the wrong font. Most were corrected in ODF 1.3, but some have slipped through, e.g.: Part Schema, 20.6 chart:axis-position, third bullet: 'double' should be 'double'; Part Schema, 20.50 chart:regression-type, sixth bullet: 'polynomial' should be 'polynomial'.

[franciscave]

Similarly, we need to check for cross-references that are in the wrong font. This occasionally happens when the cross-reference follows an element or attribute name, and the cross-reference has the character style applied and should not have.

I have counted 1 occurrence of an attribute name followed by a cross-reference number styled 'Attribute' and 82 occurrences of an element name followed by a cross-reference styled 'Element'.

[franciscave]

In Part OpenFormula section 2.1 the first sentence begins "The OpenDocument specification...". I think this should be "This OpenDocument specification..." or just "This specification...". The current wording is potentially confusing.

In Part OpenFormula, section 2.2 there is an incorrect reference to chapter 4. The reference should be to chapter 5, which is where the expression syntax is defined.

[franciscave]

In checking for attribute values containing spaces in Part 3 Schema, I used LO to search for uses of the character style 'Attribute Value' with text containing a space. I did this by modifying the properties of the attribute to include yellow highlighting, then did a search for a space with yellow highlighting applied to it.

This highlights several instances where the character style 'Attribute Value' appears to have been applied incorrectly: 10.7, 19.36, 19.626, 20.47 and 20.330.

Some attribute values have been styled 'Attribute Value Instance' (only one of these two styles is needed, I believe). There is one instance where the use of this style is clearly incorrect: 19.270.

[franciscave]

In Part 4 OpenFormula, which of the following are correct?

• OpenDocument Formula Expression (heading to 2.2)
• OpenDocument formula expression (2.2 and 2.3.1, but compare with OpenDocument Formula Evaluator, which consistently uses title case)
• OpenFormula expression (5.6).

[franciscave]

We need to check that all Notes (except possibly in tables?) use the paragraph style 'Note'.

[franciscave]

In ODF 1.3 CS02 Part Schema, section 19.381 is blank in the .odt and .pdf versions and is missing entirely in the .html version.

I believe that this was the result of deleting the attribute 'office:process-content'. Should the blank heading remain, or should it be removed and leave a gap in the numbering? I suspect that neither of these is ideal.

The blank heading (i.e. section number only) should remain, so that the following sections are not re-numbered. It may be worth adding '[deleted in ODF 1.2]' or similar in place of heading text.

[franciscave]

The following editorial issue remains to be resolved:

In Part OpenFormula section 2.1 the first sentence begins "The OpenDocument specification...". I think this should be "This OpenDocument specification..." or just "This specification...". The current wording is potentially confusing.

The following editorial issue has been resolved in the Part 4 master document draft.

In Part OpenFormula, section 2.2 there is an incorrect reference to chapter 4. The reference should be to chapter 5, which is where the expression syntax is defined.

[franciscave]

The heading 'Deprecated MIME Types' needs to be deleted from Part 3, Appendix G, as no MIME Types have changed to being deprecated in ODF 1.4.

[franciscave]

The heading 'Deprecated MIME Types' needs to be deleted from Part 3, Appendix G, as no MIME Types have changed to being deprecated in ODF 1.4.

Now deleted in the master version of Part 3, Appendix G.

[franciscave]

In checking for attribute values containing spaces in Part 3 Schema, I used LO to search for uses of the character style 'Attribute Value' with text containing a space. I did this by modifying the properties of the attribute to include yellow highlighting, then did a search for a space with yellow highlighting applied to it.

This highlights several instances where the character style 'Attribute Value' appears to have been applied incorrectly: 10.7, 19.36, 19.626, 20.47 and 20.330.

Some attribute values have been styled 'Attribute Value Instance' (only one of these two styles is needed, I believe). There is one instance where the use of this style is clearly incorrect: 19.270.

Mostly corrected in the latest master documents (Parts 2, 3 and 4). A decision still needs to be taken as to whether to retain both 'Attribute Value' and 'Attribute Value Instance'.

[franciscave]

• 4 - Part 1,3,4: Check for ISO Keywords styling: 'shall', 'shall not', 'should', 'should not', 'may' and 'need not' - replace 'must'

There is one incorrect use of "must" in Part 3, Appendix D.3 that should be "should" (note that Appendix D is non-normative, so "shall" is not allowed):

Users importing non-OpenDocument slides that contain tables need access to the table structure via their assistive technology. Therefore tables imported into an OpenDocument application from another file format should have their structure preserved, and when saved as OpenDocument should be saved as as embedded spreadsheets.

There is one use of "may not" in Part 3, Section 16.29.5, which is not a permitted form in ISO standards:

Fill characters may not fill all the available space in a cell. The distribution of the remaining space is implementation-dependent.

A better form of words would be:

If fill characters do not fill all the available space in a cell, the distribution of the remaining space is implementation-dependent.

In Part 4 there are no incorrect uses of "must" or "may not".

[franciscave]

• 3 - Part 2: Check for ISO Keywords styling: “should”, “should not”, “may” and “need not” - replace "must"

In Part 2 there is one incorrect use of "must" in Section 3.7, item 12, which probably should be "shall" ("should" would also be possible, if this is a recommendation and not a requirement):

The content of the relative IRI buffer is interpreted as a file or directory name within the package, that is, as the name of a file or directory including its relative path within the Zip file. An empty buffer denotes the package root. Path segments in the relative IRI buffer that originally came from the relative IRI shall be interpreted according to IRI syntax rules, while segments that originally came from the file entry path shall be interpreted according to Zip path name syntax rules.

There is one instance of "may not" in Part 2, in the Note in Section 3.8:

Note: Such effects might interfere with effects added to the preview images by the different file system explorers or may not be desired at all for certain use cases.

This could be better expressed thus:

Note: Such effects might interfere with effects added to the preview images by the different file system explorers or might be undesirable for certain use cases.

[franciscave]

• 1 - Part 1,3,4: Removing accidental bookmarks not defined as allowed cross-references
• 2 - Part 1-4: Replacing non-mnemonic TOC references with generated ones based on XML node names"

I believe that the names of reference marks are now correct in the WD 02 specifications.

I believe that TOC references are generated by the editing application (LibreOffice), so replacing these would need to be repeated every time that the TOC is updated in an editing session. I think this task has to be postponed until we have an improved method of editing the specifications.

I have pushed the following commits that update front matter / metadata for ODF 1.4 CSD 01:

• 34e9686

• bff2199

I will create CSD 01 by accepting changes in the master tracked documents.

[franciscave]

We need to clarify the procedure for creating formal OASIS work products from drafts in Github. The schemas and .ODT files are ready for the CSD stage, but we also need HTML and PDF files. The HTML files are generated using the Maven process, but what about the PDF files? Are these generated in the version of LibreOffice used to edit the .ODT files, or by some other means?

[mistmist]

the XHTML generation via Maven has a problem with the embedded objects (Math) and can't be used for the final work products.

how to set up LO with the xslt2-transformer.oxt Extension is documented in the README.md at the toplevel, under "LibreOffice XHTML XSLT export taking from our GitHub".

not aware if anything special is needed for the PDF.

vague memories tell me there was also some script to automate things; Svante reminded me this is here:
https://github.com/svanteschubert/odf-tc-editors/blob/main/html-via-LO.bat

there is also a acceptChanges-updateCT-via-LO.bat which automates updating all the ToCs.

[franciscave]

Thanks for pointing me in the right direction, Michael! I'll give this a go.

It looks as if I'll need to tailor Svante's .bat files to my local Windows configuration, but that shouldn't be too hard.

[franciscave]

I have run modified versions of Svante's two batch files for creating the PDF and XHTML versions of the ODF 1.4 specifications, and have pushed these to Github.