Suggestion of upcoming handling of ODF TC deliverables - earlier: Re: Editing Office Version & XML indent

[Svante Schubert <svante.schubert@gmail.com>]

Hi Francis,

I would suggest we are bringing all your working draft files into our GitHub repository.

The final ODF 1.2 artefacts are already checked in: odf-tc/src/main/resources/odf1.2

You might want to add your current state-of-work at:

• odf-tc/src/main/resources/odf1.3
• odf-tc/src/main/resources/odf1.4
  

I wouldÂsuggest to place the ODTs of all parts with the schemas flat in the directories and unzip the ODT in addition n a directory named identical aside with "_" instead of ".".

The reason for the duplication is that the XSLT is not yet able to access the XML within the ODT and Git is just better with pretty printed XMLÂfiles as with binary blobs.

On theÂother hand, for convenience, I would like to be able to open quickly open the file without zipping it myself.

There should be a script to unzip them and a pre-commit hook test that both (ODT & unzipped XML) are identical, but one step after the other.

You might as well edit the XML. Although the MIMETYPE should not be compressed, my bet is LibreOffice (LO) will fix it.

After you added your documents, we might test if an update of LO will change the existing parts by loading and saving them (aside from the metadata string).

Michael got such a regression tests AFAIR.

In addition, we might want to commit the results of our transformations as well, e.g. for ODF 1.3: odf-tc/src/test/resources/odf1.3/references

It is easier to spot regression if we have the former results of our transformations at hands in history.

Of course, the file names will change in the future according to the input, but the work is quite preliminary at this point.

As a rule ofÂthumb. All files being delivered are in the directory:Â

• odf-tc/src/main/

all other files, being mostly test and test documentsÂwill reside beyond:

• odf-tc/src/test/ÂÂ

I am reusing the Maven build system standard layout. Perhaps later we might switch to Gradle.

GitHub Pages is activated, but I want to improve it, the test commits will be cleaned up later in my fork, I have moved tests to:

https://github.com/svanteschubert/testing-github-pages/ÂÂ

For the ODF 1.3 CS02, I would suggest you work without change-tracking most of the format changes is too noisyÂin change-tracking anyway.

We should be able to track your changes in the content.xml via GIT.

Still, it would be helpful if we use GitHub commit on the deliverable artefacts as semantical steps using a certain commit pattern including the issue ID and title.

Although we are using still JIRA we might want to overtake the GitHub keywords, e.g. I suggest we use: "Fixes #242 bug title".

In case of the format task, you might add the subtask instead of the bug title.

Last but not least, later we might want to fix one task after the other. Starting with no changes in the beginning, we would enable change tracking for this task.

1. Fix the JIRA issue within the specification
2. The editor would do a pull-request, triggering via Travis several tests.
3. Another TC member as a reviewer will check the task against the JIRA issue - we might want to enable (later) branch protection for review
4. The ODT will be committed as reviewed within GitHub still with change-tracking
5. The ODT will be committed again with GitHub with all changes accepted

Now this iteration would repeat.Â

The advantage is that we have change-tracking only for this task and might generate DIFF PDF from the change-tracking ODT to show the changes related to one issue.

The disadvantage we might end up with more than one DIFF PDF if we have to start such iteration for the same issue again and we won't have one DIFF document.

As a developer, I would be happy to have a list of changes related to new featuresÂwith all changes related in oneÂPDF and/or ODT.

In addition, I never liked the all-diff-included with all the format changes, it is far too much noise, as it included all format changes as well.

Talking about PDF DIFFs they did not work out very well for ODF 1.3, there is not a single change in the XML part of part 2, which is obviously wrong:

http://docs.oasis-open.org/office/OpenDocument/v1.3/cs01/part2-packages/OpenDocument-v1.3-cs01-part2-packages-DIFF.pdfÂÂ

Therefore it's time for changes :-)

Have a nice weekend,

Svante

Am Fr., 3. Juli 2020 um 21:23ÂUhr schrieb Francis Cave <francis@franciscave.com>:

Hi Svante

Â

Iâm using LibreOffice version 6.3.6.2 for Windows 10. I update LibreOffice when prompted. If I check for updates, LibreOffice says my copy is up-to-date. I could update to version 6.4.5, but I have tended not to think if myself as an âearly adopterâ. ð

Â

I generally use the Grid view in Oxygen to read content.xml, so I havenât been bothered by the lack of pretty printing, but I have now set âprettyprintingâ to âtrueâ in my copy of LibreOffice.

Â

Kind regards,

Â

Francis

Â

Â

Â

From: Svante Schubert <svante.schubert@gmail.com>
Sent: 03 July 2020 18:43
To: Francis Cave <francis@franciscave.com>
Cc: office@lists.oasis-open.org
Subject: Editing Office Version & XML indent

Â

Hello Francis,

Â

What office version are you currently using? The meta.xml of your last document was empty, so I could not figure it out.

Â

Same LibreOffice version for editing ODF TC deliverables

It might be reasonableÂif we are working all with the same LibreOffice version for editingÂthe ODFÂspecification documents.

The idea behind the above is that multiple people can load & save deliverable documents without changing unintentionally something.ÂÂ

Therefore, I would suggest settling with the latest stable versionÂ6.4.5.2:

https://www.libreoffice.org/download/download/Â
Otherwise, state your version and I install your old one.

Â

Enabling Pretty Printing

As I would like to be able to edit the content.xml easier and get some impression on what changes you made, therefore I would, in addition, suggest enabling XML indent by LibreOffice.

Michael was so kind explaining to me how this can be enabled in LibreOffice - usual XML indent does not work as it would add whitespaces inside paragraph elements.

Two ways to enable prettyprinting:

1. Tools->Options->Advanced->Expert Configuration
   Search for "prettyprinting" and enable it.
2. Open the config file registrymodifications.xcu withinÂ
   Windows: <USER SETTINGS> = %APPDATA%\libreoffice\4\user\
   Linux: <USER SETTINGS> = ~/.config/libreoffice/4/user/
   and add the following:
   <item oor:path="/org.openoffice.Office.Common/Save/Document"><prop oor:name="PrettyPrinting" oor:op="fuse"><value>true</value></prop></item>ÂÂ

I taste option#1 successfully.

Â

Best regards,

Svante

Â