Fix authoritative sources where "(E)" is considered "Clause"

[ronaldtse]

"(E)" here is part of the original document identifier, i.e. "ISO 19107:2019(E)", not the clause. This was a mistake in the original Excel file.

I propose we move all the "(E)" from "clause" to the "source":

• source: "ISO 19107:2019(E)"
• clause: "3.34"

Ping @skalee

[ronaldtse]

There is an additional consideration that "ISO 19107:2019(F)" (French) or "ISO 19107:2019(R)" (Russian) exist too.

A translation that originates from the MLGT (this repository) should be clearly marked as such and differentiated against data that is sourced from external content (e.g. alternative language versions like "ISO 19107:2019(F)" or national standards like "JIS XXX:XXX").

(ping @strogonoff )

Relates to glossarist/glossarist-desktop#73

[skalee]

There is an additional consideration that "ISO 19107:2019(F)" (French) or "ISO 19107:2019(R)" (Russian) exist too.

@ronaldtse I'm not sure what you mean by that. There is no single occurrence of (F) or (R) in YAMLs.

In fact, grep -ho '(.)' concepts/concept-*.yaml|sort|uniq|tr '\n' ' ' produces following:

(+) (-) (/) (1) (2) (3) (6) (8) (A) (E) (H) (a) (b) (h) (i) (j) (n) (s) (t) (x) (y) (°) (λ) (ϕ) (и) (ы) (أ) (ب) (ز) (ع) (م) (ن) (∅) (屬) (恣) (曆) (逆) (類)

[skalee]

@strogonoff How to fix that in context of _revisions? Can I simply all the broken authoritative source clauses & refs everywhere, or should I add another revision, or what?

[skalee]

@ronaldtse @strogonoff Guys, I really need clarification before proceeding, especially on the _revisions thing.

[skalee]

@ronaldtse, @strogonoff?

[ronaldtse]

@ronaldtse I'm not sure what you mean by that. There is no single occurrence of (F) or (R) in YAMLs.

It doesn't exist right now but they are allowed to exist, just like (E) does.

How to fix that in context of _revisions? Can I simply all the broken authoritative source clauses & refs everywhere, or should I add another revision, or what?

Ping @strogonoff , I believe we can fix all the clauses & refs in the data because the data we have is already the authoritative set.

[strogonoff]

It depends, if this register is not yet being used we can replace data in past revisions (that is the original revision, there’d be only one revision if it‘s not used yet), if it is used we should create a new revision (author could be used the same as the one from the initial revision, “automated migration”) and let all authors pull it, but if it is used we may also run in conflicts since authors may have done changes already.

[strogonoff]

Generally, once it’s being used, any migration presupposes downtime where no one is using the app and should be planned a while in advance with notice to app user.

[strogonoff]

Since this isn’t breaking the app terribly as far as I can see, if people have worked on this registry we could schedule maintenance downtime for early August, coordinate it with some bigger app update and also do this migration.

[skalee]

Thanks @strogonoff! It explains a lot.

But now I have another question: if it's going to be a part of migration, should I use any specific toolset? For example, do you need it in JavaScript? Or can I prepare a Ruby script which will be run during migration?