Meeting minutes

Hello,

Please find below a summary of yesterday’ discussion:

Attendance: Rodolfo, Lucía, Yoshito, DavidF.

Regrets: Bryan

I. Administration

L: I move to approve 4 May meeting minutes. https://lists.oasis-open.org/archives/xliff/202105/msg00003.html

R: I second.

L: Meeting minutes approved.

II. Technical discussion

Proposal: mark attribute “startRef” as required in <ec>. Rodolfo. https://lists.oasis-open.org/archives/xliff/202105/msg00005.html

Df: if the ec is isolated, it does not have id. It must be an ec in the same unit.

R: how do I know if ec is in another unit?

Df: we are not matching if they are not in the same unit.

Y: that means that the data should be defined in the same unit.

Df: any inline

R: what would be the difference between an isolated ec and a ph?

Df: if you have an isolated ec that it runs until the start of the unit. The corresponding artefact may be not in the xliff at all. The ph is atomic. But ec it meant to form a span.

It is described in the inline section. It is described there. It is the subcommittee lead by Yves

R: we are not pairing ec and sc.

Df: we do in unit. Isolated means that is orphan in the unit.

Y: so even if the pair starts in another unit. Xliff forces you to have it in the unit.

Df: the scope of the ids are described. The id scope is in the unit.

The value of starRef is NMTOKEN from inside the unit. If the value would be URI, then fragid could be used.

That is a special case of isolated.

For em the startRef is required.

Df: If you are in control of the extracting mechanism.

R: the user usually makes mistakes with that.

Online Validation Tool. Feedback, next steps. https://lists.oasis-open.org/archives/xliff/202101/msg00002.html

and Test suite correction. Schematron (update?).

R: I have been working on fixing of the problems in my tool.

R: David, Have you had to look at the issues to the schematron?

Df: No, sorry, I did not have the time.

R: Rodolfo points a problem (line 113 in the document) “Pairing <sm> with <em> is not required.”

Df: For em if follows, but it does not follow for <sm>. That is something to fix in the next version.

I will have a look at the spec.

R: We should have it in the definition of <sm>, not on 20 pages later.

Df: it is in the annotations section. I can add that requirement explicitly in the element description.

R: I have identified a bunch of schematron errors. I hope that I can fix the problems related to my tool next weekend so I can announce a new version of the validation tool and ask for feedback. It would be good if he schematron would also be fixed.

Df: (rodolfo shows a file of the test suite that is supposed to be invalid but it is valid).We could rebrand this case.

L: Have we discuss a specific plan for the new version of the test suite?

Df: the test-suite is not part of the standard. We can release a new version when it will be ready.

R: We have to fix it to produce a new version.

Df: we could change this in svn because the spec is pointing to the svn.

R: I would change it on both locations (github and svn)

Df: when we will have the final version in gitub we can populate it in svn.

L: When would you think that they would be ready? It is just a logistic question, not to put pressure on you.

R: I need to finish working on the validation tool that I plan to have ready by the next meeting in two weeks. Then I will work on this. I will have to check all the valid again as I have made changes in the tool and some files that were valid might not be valid anymore and vice versa.

L: I just wanted to know about the logistics, I can review the modified files once you will have the new version.

R: For example (line22) is not supported by the validator, so I still do not know how to do with this.

(Rodolfo shares his screen and we try to understand why the validation marks this as invalid)

Df: It seems valid to me.

R: I think it is because “xyz:comment” is not valid. If it is not a registered extension so it is not valid. We can change the example, and include a valid register. In one of the tc pages, it is also said that. If you have an extension, you must register with the XLIFF TC.

Y: Do we have a repository?

Df: We do.

Y: if we do, we should be able to programmatically from the svn.

Df: I think we have a valid registration, its.

R: the other one is “my” that is used in the example.

Df: ITS, In 2.1 is a module, in 2.0 is an extension.

Df: the registration procedure is in wiki, and the actual register is in svn.

R: I think I saw it in the wiki.

Df: I remember that there was a problem with svn.

R: Yes, it is in svn. There are my and its.

Df: we should add ‘ctr’, it is described as an extension in 2.1.

III. Subcommittee and sister TC reports

MessageFormat (XLIFF 2 module). https://docs.google.com/document/d/1D702OBAzT-Crb9XXUiZYJnFO9Yq5duRy4Zc3Br6JwRU/edit

Df: From the message format, the both data models have proposals for 2.1 modules. It will be basically create groups and it is compatible with core. https://github.com/messageformat/messageformat/tree/mf2/packages/xliff

R: I remember that it needed changes in inline.

Df: that was the older version, the new one is valid already.

xliff message