Re: [office] Status of Committee Specification Draft 02 -- earlier (Re:

Subject: Re: [office] Status of Committee Specification Draft 02 -- earlier (Re: [office] Agenda for ODF TC Teleconference Monday, 17 August 2020)

Hi Francis, Hi Patrick,

I would like to add the two topics below to the agenda:

1)Â

As mentioned earlier - Michael and I will aim to work for ODF 1.4 on embracing more automation:

https://lists.oasis-open.org/archives/office/202007/msg00078.htmlÂ

Paul from OASIS naturally likes the idea as it involves less manual work:

https://lists.oasis-open.org/archives/office/202007/msg00082.html

We have already some success stories:

For instance, in ODF 1.3 CS01 our ODF-HTML was manually fixed (e.g. style colour and line-height), now there should be no post-processing required.Â

Still, we are ready yet and there are some things to be changed by OASIS manually, asÂthe copyright date, voting date, etc.Â

I would suggest toÂoffer them to do this on top of our GitHub versioning control system.

The relevant directories for OASIS were mentioned at the end of:Â
https://lists.oasis-open.org/archives/office/202008/msg00025.htmlÂ

I am not sure if this is our part of work or OASIS, but I would love to add some metadata to our meta.xml, which seems in ODF 1.2 empty and is currently:

Although this might already be part of the OASIS work,Âwe might want to give a suggestion.

Especially our HTML would add the above as metadata and our HTML specs documents would be better findable by search engines.

2)Â Â

Inspired from these fields, I would like to suggest to name officially a few more editors, like you Francis, aside of Patrick, but I have not found any notes on the process of TC editors. To me, editors are those taking care of the TC's deliverables and integrating the change-suggestions of the JIRA issues into the ODTs & RNGs.

Therefore, I would like to suggest adding Michael and myself as well as official editors of the TC as we are about to add more and more the software perspective of automation to the creation and validation of the TC deliverables by using GitHub. Our work on our TC GitHub repository has barely started and it is more a prototype or alpha state, but already served its purpose to find and fix several issues and allow better reviews. What do you think?

Looking forward to talking to you,

Svante

Am Mo., 17. Aug. 2020 um 17:02ÂUhr schrieb Patrick Durusau <patrick@durusau.net>:

Svante,

I hate to disagree with Francis but "stone-age" really should be late 1940-ish (Think mailing hard copy made with carbon paper). They have barely moved since then so stone-age is hyperbole. ;-)

Patrick

On 8/17/20 6:08 AM, Francis Cave wrote:

Hi Svante

We're not so much in disagreement as it might appear. If the text were generated from a formal, machine-interpretable source, the use of complex natural-language structures would (naturally) be avoided, so all instances of "may" would be keywords. All I'm saying is that such checks could not be fully automated on the current, hand-crafted text. I'm not against it in principle!

Incidentally, I think your use of "stone-age" is very harsh... but spot on!

Kind regards,

Francis

Sent from my iPad

On 17 Aug 2020, at 10:47, Svante Schubert <svante.schubert@gmail.com> wrote:

Hi Francis,

Am Mo., 17. Aug. 2020 um 11:16ÂUhr schrieb Francis Cave <francis@franciscave.com>:

Hi Svante

The short answers to your questions are:

1. No. In fact, typographic highlighting of words such as "shall" is not allowed in standards developed within the ISO process. The purpose of styling such words with a named character style is, so far as I understand it, not in order to make them appear different to the human reader of the text, but as an aid to the editors and possibly to users of the HTML version checking which provisions are mandatory, which are recommended, which are optional, and which behaviours are forbidden.

2. According to ISO editors, who were recently asked this question, a paragraph is non-normative if it doesn't contain any ISO keywords. In fact, ISO now say that, apart from indicating that a whole Appendix is non-normative (actually they use the word "informative"), by adding the word "informative" to the subtitle of the Appendix, such wording is not necessary and should be avoided.

Thank you very much for your quick reply and interesting answers.Â

I agree withÂyou now and have moved the keyword handling to ODF 1.4 on my ToDo list as well.

I disagree that styling of ISO keywords can be completely automated. There are definitely contexts in English, such as in subordinate clauses, where the use of "may" is correct (its use as a subjunctive verb, for example) but is not to be interpreted as an ISO keyword. I don't believe that it would be practical to implement the natural-language processing that would be necessary to check all such instances. However, since uses of "shall", "shall not", "should" and "should not" should always be in the strict sense, checks on these terms could be automated.

It feels like our view upon worlds might be colliding here, so we do not have to clarify this here and now. ;-)

In my opinion, from a software engineer perspective, the ODF specification as a blueprint for software should aim to become more and more part of the automated CI/CD process. I notice a technological gap - especially in terms of using automation - between "companies" such as ISO ('stone-age') and Google ('technological-frontier').

Nowadays in (new) software, every feature should be able to be tested automatically. If the feature is without an automatic test, it does not exist.

Therefore, if it is possible to add an automatic test for this highlighting, we should add one.

If this requires that we keep control of our English context and if necessary flag all similar none ISO Keyword as false-positives, so be it.

Talk to you soon,Â

SvanteÂ

Kind regards,

Francis

Sent from my iPad

On 17 Aug 2020, at 09:15, Svante Schubert <svante.schubert@gmail.com> wrote:

Hi Patrick, Hi Francis,

I have two unanswered questions myself, I might have asked before:

Is our "ISO Keyword" highlighting by character style mandatory or optional to become an ISO standard?
You sent me an ISO reference:Â
https://isotc.iso.org/livelink/livelink?func=ll&objid=4230450&objAction=browse&sort=name&viewType=1
There are 150MB of 84 files with additional referencesÂto other sites.
I fullyÂtrust you, Patrick and Francis, as our ISO experts to clarify this issue. :-)

We surely do not want to create later an ODF 1.3 corrigenda on ISO level to solve such a problem.
I only wrote a very tiny ISO corrigendum for ODF once for Sun, it took me a full week of stubborn copy & paste: stating every erroneous occurrence by page number with before and after state.Â
If there is any doubt that the styling is optional, we need to fix this before submitting ODF 1.3 to ISO.

How are all the informative parts identified in ODF 1.3?Â
Is the following covering all informative parts?

Every informative chapterÂisÂcontaining a substring: "(Non normative)"

In addition, within a chapter may occur informative parts - as explained in Terminology:
"Text with a gray background color which is contained in boxes is informative."

In any case, all "ISO Keyword" changes should be done (semi-)automated from the XML side and not by reading and manual editing.Â

The latter is obviously too error-prone and time consuming.

Your question I have answered below, Patrick.

Am Mo., 17. Aug. 2020 um 03:17ÂUhr schrieb Patrick Durusau <patrick@durusau.net>:

....

4. Status of Committee Specification Draft 02? It isn't clear who has the editing token. We need a final version for voting.

Status of Committee Specification Draft 02. There are only editorial changes on, which might be readily integratedÂat the start of our call.

The latest reviewed state of ODF 1.3 CS02 deliverables are within our TC GitHub repository:

ODT, RNG, OWL:Â
https://github.com/oasis-tcs/odf-tc/tree/master/src/main/resources/odf1.3Â

ODT-as-HTML and Defaults XML:
https://github.com/oasis-tcs/odf-tc/tree/master/docs/odf1.3Â

RNG-as-HTML:
https://github.com/oasis-tcs/odf-tc/tree/master/docs/odf1.3/cs02ÂÂ

Ongoing/pending reviews:

https://github.com/oasis-tcs/odf-tc/pulls

My general editorial ToDo list:

https://github.com/oasis-tcs/odf-tc/issues/21ÂÂ

As you might notice from the checkboxes, I was not able to work as I hoped I could at the weekend.

Until our call, I am in possession of the "virtual editor token(s)" - created for each unmergable ODT documents - please tell me if you need one or a fix.ÂÂ

Talk to you soon,

Svante

Â

...
-- 
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 

office message