Description:
See the private action item for dial in details
https://www.oasis-open.org/apps/org/workgroup/xliff-omos/members/action_item.php?action_item_id=3822
==========
Agenda:
A. Admin
1- Roll call
? out of 6 voters
aprove minutes from 24th April 2018, 22nd May 2018
https://www.oasis-open.org/apps/org/workgroup/xliff-omos/email/archives/201805/msg00003.html
https://www.oasis-open.org/apps/org/workgroup/xliff-omos/email/archives/201805/msg00007.html
B. Material
1- XLIFF OM
OM wiki needs aligned with current JLIFF structure as per 0.9.7
https://github.com/oasis-tcs/xliff-omos-om/wiki
2- JLIFF
(https://github.com/oasis-tcs/xliff-omos-jliff)
Consensus on boolean vs a yes/no enumeration restated:
Stick with yes/no enumeration becuase boolean default is false, while XLIFF defaults are yes.
ACTION ITEM: [pending]
David-> Email the working list about keeping yes|no strings (according to the discussion today) and hearing Phil’s perspective as well as others.
AI Robert
Express all XLIFF 2.1 and 2.0 modules in JLIFF schema. Have 2.1 and 2.0 branches
*[Review progress]*
Robert seeked gudance on ITS module, given on 24th April
Previous Consensus: restated
We agreed to work on 2.1 branch first and only then fork the 2.0
DON'T reference the context file [for core and module] from schema or instances. This is tied via the spec [driven by version number] but not the instances, to prevent hammering of the context file.
Do we need to use a different separator for modules? underscore "_"?
Extensions always need to declare or reference their context inline.
AI Robert [DONE], implement meeting consenus for extension points. Extension data needs to start with context. Each extension will be one object. Try to allow them only where they're allowed in XLIFF
reviewed "element" extension points implemented as has map rather than an array in the latest commit https://github.com/oasis-tcs/xliff-omos-jliff/commit/85e7c3e0e8d88539df5b2eb7519d6735f84256e9
Consensus restated::
Don't use external context for extensions.
All extension context must be stated inline to avoid parsing external context files..
We also agreed that having a dedicated extension container is more validation friendly than just allowing additional properties on the root structure..
-Continue discussing pros and cons of the extensionsData approach
compare with XML and consider going back and forth between XML and JSON.
3- TBX Mapping
TBX-Basic mapping is in order, almost done on TBXInfo
Update from James?
C- Other Topics
3- Promotion
Also Phil JLIFF library open sourcing was announced in the GALA week
https://twitter.com/VistatecGlobal/status/974538466565373952
https://twitter.com/merzbauer/status/974288543093854208
GALA TAPICC needs to work on launching JLIFF based Track 2
Will probably launch by end of June
4- AOB
1- Date of next meeting
26th June 2018
==========
Minutes:
Agenda
A. Admin
1- Roll call
4 out of 6 voters:
David Filip,
Robert van Engelen,
James Hayes,
Steven R. Loomis
aprove minutes from 24th April 2018, 22nd May 2018
https://www.oasis-open.org/apps/org/workgroup/xliff-omos/email/archives/201805/msg00003.html
https://www.oasis-open.org/apps/org/workgroup/xliff-omos/email/archives/201805/msg00007.html
David: We need to approve two minutes. The news is James is now secretary of XLIFF OMOS.
David: Move that 24 April and 22 May minutes be accepted.
Robert: Second
[No dissent]
MOTION PASSED
B. Material
1- XLIFF OM
OM wiki needs aligned with current JLIFF structure as per 0.9.7
https://github.com/oasis-tcs/xliff-omos-om/wiki
2- JLIFF
(https://github.com/oasis-tcs/xliff-omos-jliff)
Consensus on boolean vs a yes/no enumeration restated:
Stick with yes/no enumeration becuase boolean default is false, while XLIFF defaults are yes.
ACTION ITEM: [pending]
Previous Consensus restated::
Don't use external context for extensions.
All extension context must be stated inline to avoid parsing external context files..
We also agreed that having a dedicated extension container is more validation friendly than just allowing additional properties on the root structure..
-Continue discussing pros and cons of the extensionsData approach
compare with XML and consider going back and forth between XML and JSON.
Robert: I updated the schema according to the discussion in the previous meeting relating to the ITS module. We prioritized items which were still missing, which I have added.
5.9.5 ITS Tools has been added now (annotatorsRef), which is an attribute in XLIFF, a property in JLIFF.
Also added 5.9.6.2 "domains" (@ in XLIFF, prop. in JLIFF) with string content. on elts file, group, unti.
David: Also needs to be on <sm> and <mtc:match>
Robert: locQualityIssues (a standoff elt) was missing last time. It has now been added (line 791 of jliff-schema-2.1.json).
I also defined the locQualityIssuesType so it would not need to be defined twice. It is also used elsewhere in <sm>
provenanceRecords ref and standoff of provenanceRecords have been added.
Robert: We have to look at the ordering (which is not related to the spec). I think it lacks structure so we should revisit adding dash prefixes
David: I do think we will need a "-" instead of a ":"
Robert: Yes.
David: I think "-" will be good for readability.
Robert: Tool Annotations has been added to <em> and <sm>
David: It shouldn't be on <em>. It is also on structurals (file, unit, group). Unfortunately it is not in the XLIFF spec, but it is in the W3C spec.
Robert: That does make it harder to verify. So, to confirm: it should only be on <sm>, and the structural elts
Steven: Does ITS itself have a schema?
David: No, but on W3C interest group there is some experimentation on how to express ITS.
Steven: I am wondering if, if ITS it is just an array, in JSON, the value should just be an array?
David: Can you have a single member array in JSON?
Robert: Yes
Steven: So, {in chat} "its-annotatorsRef": [ "mt-confidience", "MT1 terminology", "ABC"]
Robert: Yes, this is just replacing the space separated list with a proper array in JSON. mt-confidence and M! terminology would be separated by a |
Steven: Like this? {in chat} "its-annotatorsRef": "mt-confidience|MT1 terminology|ABC",
Steven: If it is trying to be more like an object, we could treat it as a dictionary: {in chat} "its-annotatorsRef": { "mt-confidence": "MT1", "terminology": "ABC" }
David: There is an experimental JSON ITS, but it has not been further developed (http://www.w3.org/International/its/wiki/JSON%2BITS)
Robert: Are the keys unique?
David: Yes, it should be unique. But the right hand side may be more tricky, because there is no way to prevent the right hand side.
Robert: That is fine, as long as the keys are unique.
David: Perhaps it would also be better to use an array with "domains".
Robert: After I do 5.9.7, the schema should be nearly finished.
[LINKS FROM CHAT]:
https://www.w3.org/TR/its20/#datacategories-overview
https://www.w3.org/TR/its20/#its-tool-annotation
[ACTION ITEMS]:
Robert: look into mtc:match: Add "domains" to translationCandidatesMatch.
Robert: remove Tools Annotations from <em>, add to the structural elements (file, group, unit)
Robert: create RegEx for value of annotatorsRef
Robert: Serialize annotatorsRef as an dictionary.
Robert: Serialize domains as a non-zero length array
Next Agenda: Feedback on prefix solutions
David: Get feedback on the yes|no question
3- TBX Mapping
TBX-Basic mapping is in order, almost done on TBXInfo
David: TBX Steering Committee are in Hangzhou and James and I had a productive editorial meeting for the mapping.
C- Other Topics
3- Promotion
Also Phil JLIFF library open sourcing was announced in the GALA week
https://twitter.com/VistatecGlobal/status/974538466565373952
https://twitter.com/merzbauer/status/974288543093854208
GALA TAPICC needs to work on launching JLIFF based Track 2
Will probably launch by end of June
4- AOB
1- Date of next meeting
26th June 2018
Tentative 10th July 2018
==========
Attendance:
| Meeting Statistics |
| Quorum rule |
51% of voting members
|
| Achieved quorum |
yes |
| Individual Attendance |
Contributing Members: 4 of 19 (21%)
Voting Members: 4 of 5 (80%) (used for quorum calculation)
|
| Company Attendance |
Contributing Companies: 4 of 15 (26%)
Voting Companies: 4 of 5 (80%)
|