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 5 voters
aprove minutes from 10th April 2018
https://www.oasis-open.org/apps/org/workgroup/xliff-omos/email/archives/201804/msg00004.html
B. Material
1- XLIFF OM
OM wiki needs aligned with current JLIFF structure as per 0.9.5
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 targeting 24th April, good chance to complete by then.
Robert seeks gudance on ITS module
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.
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
4- AOB
1- Date of next meeting
8th May Cancelled,
22nd May
2- Looking for a new secretary. Contact dF
==========
Minutes:
OMOS 2018-04-24
Attendees: robert, david, phil (minutes), steven Apologies: yves
Approve minutes of last meeting
rve seconded minutes
1. jliff changes
rve: commit b43755 schema 0.9.6 ...pc, mrk and cp were added but are not needed. ...Format Style and validation modules added ...consistently use plural forms for arrays ...match to matches ...metadata is one word so no camel case (metaData) ...everything is there except for ITS ...pc, mrk and cp were added just so there was a version which mirrors XML ...that way I don't forget to model something ...limited ability to add notes to json schema
df: we need to start the prose of the specification to capture some decisions and reasons ...I already started the prose for the object model but it is out of date ...please keep track of things in the wiki
rve: the wiki needs a tidy up
df: at this point we have a one-to-one copy of XLIFF 2.0 ...<ph/> should be in jliff ...<pc/> is pair of <ec/><sc/>, so no need for <pc> and also no need for <mrk> and <cp>. Early concensus not use those as XMLisms.
rve: I agree pc are xml specific but nothing to stop us having them in jliff ...syntax-wise not needed but perhaps from a semantic perspective?
df: cp is not needed in jliff
rve: happy as long as semantics can be preserved ...cp semantics would be lost during round trip ...I'll make a note in the schema
sl: we have done transformations from LDML to json ...when we go to json we flatten out some things ...ldml made a decision to never have mixed text and entity values in the schema
df: XLIFF 2 as weel, in 2.0 and 2,1 (and on) original data is stored on unit level outside of the inline data model.
sl: LDML also abandoned using cp and switched to CDATA section for content that has complex syntax
df: if you ignore cp you'll loose it
sl: json escaping rules should be able to cope with
rve: in json there are just escapes for quotes
sl: we need good examples of xliff converted to jliff and the other way around
rve: let me add notes to the schema and the wiki
2. ITS
rve: the difference I perceieve for ITS ...ITS is quite unclear how to mesh with json content ...how do we approach it?
df: think of ITS as a number of modules ...it is originally a W3C spec ...intended for native content formats ...it is a metadata format ...in xliff it can annotate source, target and structure ...5.9.6 are features not existing in xliff ...but in 5.9.7 there is partial overlap with xliff features ...5.9.8 are metadata categories we probably don't need to care for in JLIFF
sl: we've used jsonpath to some extent ...incompatible specifications and implementations
df: 5.9.9 can be ignored ...they are not represented in the serialization ...you probably need to look at 5.9.5 [ITS tools referencing orthogonal to the rest of the ITS Module], 5.9.6 and 5.9.7 as if each is an individual module ...inline only can just be applied to <sm/> ...structural is another matter
rve: okay then we'll explicityly add properties to unit, group and sm ...I'll give it a shot
df: please create 0.9.7 version of JLIFF schema without pc, mrk and cp ...then you're done with xliff 2.0 ...then create a branch for 2.1 weher u can start adding ITS
rve: I'll create two sub-directories in the branch ...will we call them jliff 2.0 and 2.1
df: yes, I think so
rve: modules are built-in ...for extensions it makes sense
df: we want them recognisable as modules but not using fully qualified names
rve: you can't have both
df: we can look into another sort of separator, maybe an underscore "_"..
3. Next meeting is 22/5/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 6 (66%) (used for quorum calculation)
|
| Company Attendance |
Contributing Companies: 4 of 15 (26%)
Voting Companies: 4 of 6 (66%)
|