Hi Paul, Hi Chet,
We already discussed the idea earlier to automate the OASIS updates on TC deliverables:
Unfortunately, the state of our TC's GitHub is at the moment rather a prototype, the tooling rudimental, so there are yet no placeholders within the artefacts being exchanged by configuration files using content from OASIS (like copyright, voting date, etc.).
Nevertheless, I would like to take the opportunity of the upcoming ODF 1.3 delivery to start improving our processes and align them better.
The first step is to get a list of what OASIS would have to change for future releases.Â
Imagine the following files would be voted for ODF 1.3. What would you need to change?
I might assist you in creating, altering these artefacts and also might upload some windows based files for batch-processing (I have not done yet as they are not running out-of-the-box).
There are some tricks and constraints, for instance, every editor has to use one exact LibreOffice Version with certain configuration (e.g. "XML indent/pretty-printing" and conformant ODF 1.2 output) to lower the risk of anomalies between editors - I would like to ask you to do the same or let me do the editing :-)
In addition, we have now reviews on GitHub for changes and the changes of OASIS should be reviewed like any other changes.
The second step would be how new design/style requirements from OASIS could be integrated in our TC GitHub process.
Regina and I believe that it would be helpful to embrace the usage of an ODF template (OTT), where we are overtaking the title-page in the content.xml and inserting data from configuration files.
Equally, for meta.xml and for the styles.xml we should strive to narrow the differences between various styles.xml.
In other words, we would be generating the ODT deliverable always from the given template. Changes made by LO on the output would need to be extracted to the content part.Â
Sounds complicated but quite easy, when we are using a library such as the ODF Toolkit's ODFDOM.
It's a long way, but this call is just to get in touch and exchange ideas and receive requirements on the changes on our deliverables after the TC has voted successfully on them (hopefully next Monday).
Do you have perhaps a 30-60min time slot?Â
We might stop immediately when we clarified step 1, but I am curious about step 2.
The definition of done of step 1 is a list of changes to be made on the list of our deliverables above.
I suggest I apply your required changes afterwards upon the GitHub files (after the successful TC voting) and you review those changes afterwards.
Best regards,
Svante
Paul,
The ODF TC is right on the edge of a new CDS to submit for public review
and I would like to have a conference call with you, including Francis
Cave and Svante Schubert, concerning the processing of that submission,
prior to our submission of the zip file with appropriate directories.
The thinking in general is that if you/TC Admin can edit the files in
our github directory (Svante assures me this isn't hard), then the final
submission in the zip file will have been approved by the TC, with all
the production changes.
Anyway, we would like to have a conference call with you to discuss this
as it would be a change to your current processing of TC submissions.
Svante says the HTML/PDF versions would be part of our submission,
saving you the time/effort to produce the same.
I'm pretty much at your beck and call this week, Francis and I suspect
Svante both prefer mornings on the East coast times.
Thanks!
Hope you and yours are at the start of a great week!
Patrick
--
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau