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

Attendees (4):

David Filip, James Hayes, Robert van Engelen, Steven R. Loomis

aprove minutes from 27th March 2018

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

Minutes approved, seconded by Robert.

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)

Discuss pros & cons of boolean vs a yes/no enumeration

Robert: In order to stay closer 1-1 with XLIFF, JLIFF should perhaps use yes/no rather than true/false.  It also stays closer to the three values (yes, no, firstNo)

David:  I think that we don’t necessarily keep the odd XML implementations such as yes/no instead of Boolean.  What are your thoughts Steven on this?

Steven: When it is strictly Boolean, true/false is better for less ambiguity.  Also, sometimes serialisers don’t support custom Boolean values.

David: I think the Boolean semantics are only on canCopy (yes|no), canDelete(yes|no), both "yes" by default

Steven: Maybe, for something that defaults to yes, it may be better to have cantDelete, so it defaults to being false, according to the concept of “falsey”.  But this diverts from the XML XLIFF behavior.  Basically, in JavaScript, if the key is absent, the default value is false.  But the compatibility with XLIFF may be more important than “falsey” in this case.

David:  This may be a good argument for not going with Boolean, because we don’t want these to default to false when missing.

Steven:   Yes, if we keep the string yes|no values, only an explicit value of “no” would be counted as a no because “yes” would be counted as yes and absent would be also counted as yes. So, I would say go with yes|no rather than true|false.

David: In the OM I think it’s Boolean, but this is a good reason to go with the yes|no enumeration, restricted from string. Flipping canDelete->cantDelete and using double negation for yes would be an odd thing to do..

Robert: I think we can move forward with keeping yes|no, and hearing Phil’s comments on this will be good. 

ACTION ITEM:

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: No progress today, targeting 24th April, good chance to complete by then.

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 external context for extensions or not?

David:  Do extension owners have the option to reference external context files or do they need to state the context inline?

Robert:  I though the inline context was beneficial for several reasons.  It prevents additional loads from external sites. It would increase bandwidth requirements to allow external files, so I am in favor of inline.

David:  Let’s move forward with keeping it inline then.

- 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.

Robert: I don’t see any real challenges at this point, but I anticipate this being a lot of work.

3- TBX Mapping

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

Update?

David: James and I had TBX editorial meeting just before this meeting

James:  We are working to show the mapping for both TBX styles (DCA and DCT) as well as deciding which references to use as normative references. 

C- Other Topics

Skipped

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

22nd May

Robert: I would be happy to chair one of the meeting between now and 22nd May.  I can chair the 24th of April.

David: I am unsure if I can chair the 24th April or the 8th May due to travels

Robert: I will not be able to attend the 8th May

David: Ok, let’s cancel the 8th May and try for 24th April.

2- Looking for a new secretary. Contact dF

Meetings:

24th April -> chaired by Robert

8th May -> Cancelled

22nd May -> chaired by David

A. Admin

1- Roll call

? out of 5 voters

aprove minutes from 27th March 2018

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

Discuss pros & cons of boolean vs a yes/no enumeration

AI Robert

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

*[Review progress]*

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.

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

22nd May

2- Looking for a new secretary. Contact dF

• OASIS Open (General Membership)
• General Public