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:
Rollcall
Scribe
Approve minutes from 10th July
https://markmail.org/thread/mzmiaxk5fopgrtye
and informal minutes from 11th Sep
https://markmail.org/thread/ytbo7uk322ww3o2t
Discuss pefixing of modules in schema
https://markmail.org/thread/k6ly2renp7jw26s3
Setup of prose spec
Future meetings
Skipping 9th October due to dF travel, 23th October, 30th October?
AOB
==========
Minutes:
Rollcall
Alan, Steven, Robert, dF
Scribe
dF will write minutes post hoc
Approve minutes from 10th July
https://markmail.org/thread/mzmiaxk5fopgrtye
and informal minutes from 11th Sep
https://markmail.org/thread/ytbo7uk322ww3o2t
No dissent, minutes approved
Discuss pefixing of modules in schema and instances
https://markmail.org/thread/k6ly2renp7jw26s3
We first discussed the most advanced wrapping proposal from Phil
It was perceived as a win loose that works great on strctural levels but would add to much complexity and "syntactic gravy" to inline occurences
The advantage would be that it feels as a very clean JSON approach not tainted with XMLism
We were not sure if the wrappers are going to produce extra processing complexity, especially on transforms to and from XLIFF.
We clarified that the current Robert's solution uses "_" at the top most module object, it is important to note that many times especially at the inline level the top most object is also the leaf.
We discusse other options, but the current seemed best.
The motivation for using prefixes was using the JSON-LD syntax for the work with fully qualified names for extensions. We originally though of using the same mechanism for modules. But we decided against directing JSON-LD processors to public OASIS hosted JSON-LD context instances. So we agreed that the module context will be semantically documented in the spec but not syntactically present in the schema and instances.
Prefixing of module objects with "_" does not have syntactic significance, it's only for human readability..
JLIFF has an interesting adavantage against XLIFF as it unambiguously distinguishes between module and extension instances.
Setup of prose spec
Prose spec needed to support early adopters. We want to cover recurring questions such as why there is no pc, why there is no preserve space. But the spec needs to structurally cover the whole schema and provide implementation guidance..
dF will set up prose spec as top level folder on the existing jliff repo
https://github.com/oasis-tcs/xliff-omos-jliff/
dF will ask OASIS to become the second maintainer, Steven fine to contribute PRs.
Robert: we are a small group so why not have write access for everyone?
dF: it is a best practice to use PR even as maintainer. For now we are fine with writing directly, as we are in working draft. But from first public review on we should do changes only based on issues via PRs
Future meetings
Skipping 9th October due to dF travel, 23th October
The group is small and we will switch to monthly, aiming to maximaize work over mailing list and GitHub repo
AOB
Alan wants the OMOS TC to form a liaison with ASTM F43. dF to check with OASIS admin if there is a MOU between ASTM and OASIS. Alan to check the same from ASTM end. The purpose is to harmonize work on error categorization and serialization thereof via XLIFF/JLIFF ITS module.
Alan proposed to work on a JLIFF version of TBX. dF to check, whether this would be in scope. If that work starts it should start with the subset preset in the XLIFF gls mapping
Meeing adjourned
==========
Attendance:
| Meeting Statistics |
| Quorum rule |
51% of voting members
|
| Achieved quorum |
yes |
| Individual Attendance |
Contributing Members: 4 of 18 (22%)
Voting Members: 3 of 5 (60%) (used for quorum calculation)
|
| Company Attendance |
Contributing Companies: 4 of 15 (26%)
Voting Companies: 3 of 5 (60%)
|