search

oasis-tcs / odf-tc

OASIS OpenDocument TC: Providing version control for developing the OpenDocument Format (ODF) file format and related tools beginning with ODF CS 1.3 https://github.com/oasis-tcs/odf-tc
Other
14 stars 3 forks source link

Checklist for ODF 1.4 #27

Open svanteschubert opened 4 years ago

svanteschubert commented 4 years ago

Postponed to ODF 1.4:

franciscave commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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

franciscave commented 2 years ago

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

franciscave commented 11 months ago

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 commented 11 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 9 months ago

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 commented 8 months ago
  • [ ] 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 commented 8 months ago

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 commented 8 months ago
  • [ ] 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:

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

franciscave commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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.