OASIS Open

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

A. Admin

1- Roll call

3 out of 5 voters

(David, Robert, Yves).

aprove minutes from 27th Feb 2018

https://www.oasis-open.org/apps/org/workgroup/xliff-omos/email/archives/201803/msg00000.html

D: those are the minutes for last call.

R: second

No dissent.

D: Minutes approved

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

R: worked on implementing moduls.

.. discussion on extensions

.. seems it would be nice to keep compatibility with XLIFF 2.1.

.. for example "yes/no" enumertaions rather than the boolean type

.. so used that in JLIFF too for consistency

.. did a commit.

.. D, you had concerns?

.. we can change if needed

.. idea is to reduce the surprise level

D: think yes/no are semantically boolean in XLIFF. Boolean is a very well established type in JSON and elsewhere

Y: no preference

.. representation is one thing, object implementation is another

D: custom enumeration may be more annoying when working with libraries, boolean is widely supported

Y: boolean is clear, doesn't need to be yes/no can be true/false or whatever but it always maps

R: working on the remaining models.

.. looking at the XLIFF structure and OM.

.. don't see any obstacle so far

.. too busy to work much on this lately.

D: did some discussion at GALA Boston. TAPICC launched only Track 2 and not Track 3, so we have some slack with modules. T2 is fine with core.

R:

.. JLIFF schema will be based on 2.1

.. we may have a 2.0 branch

.. addeed v0.9.6 with the boolean to enum

.. this is a new file

.. added glossary entry, resource, change-track, translation candidates

.. looked at prefix for values in Translation Candidates

D: yes, not a namespace prefix in attribute values, but used in the same way

R: this is coming, slowly but coming.

.. maybe done by the next call.

D: Worried about Chase participation

Y: not sure. he seems busy.

D: any chance to look at Phil's library?

https://github.com/vistatec/JliffGraphTools

Y: did not have a chance to look at it.

D: currently you can make a JLIFF out of an XLIFF

.. could be linked to an extractor using the events

Y: yes, but Java and .NET won't mix at that level

D: next call April-10

End of the call

A. Admin

1- Roll call

? out of 5 voters

aprove minutes from 27th Feb 2018

https://www.oasis-open.org/apps/org/workgroup/xliff-omos/email/archives/201803/msg00000.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)

AI Robert

Express all XLIFF 2.1 and 2.0 modules in JLIFF schema. Have 2.1 and 2.0 branches

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

Discuss:

Use URI type of context or not?

- Continue discussion on extension points, look at Robert's commit to introduce extension

https://github.com/oasis-tcs/xliff-omos-jliff/commit/85e7c3e0e8d88539df5b2eb7519d6735f84256e9

 There are several places where context can be provided: root, or units, files, groups. 

  (Whether @context should be at root or only lower levels).

Should mimic XLIFF behavior as close as possible..

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.

AI dF and Yves [DONE]: clear usage of XLIFF prefix registration mechanism for JLIFF, request that XLIFF prefixes don't use colon ":"

raised on XLIFF TC 16th Jan

DONE in principle, some minor fixes pending, e.g. FAQ

http://markmail.org/thread/qmvyp4yuihx76g6r

3- TBX Mapping

TBX-Basic mapping is in order, almost done on TBXInfo

Update?

C- Other Topics

2- Liaisons

XLIFF

TAPICC - Track 2

3- Promotion

Had good coverage on GALA Boston in March, as TAPICC Track 2 was launched, building on JLIFF

Also Phil JLIFF library open sourcing was announced in the GALA week 

https://twitter.com/VistatecGlobal/status/974538466565373952

https://twitter.com/merzbauer/status/974288543093854208

4- AOB

1- Date of next meeting

10th April?

2- Looking for a new secretary. Contact dF

• OASIS Open (General Membership)
• General Public