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

David, Chase, Phil, Yves, Robert, James

6 out 7 Voters total

B. Material

1- XLIFF OM

(https://github.com/oasis-tcs/xliff-omos-om)

2- JLIFF

(https://github.com/oasis-tcs/xliff-omos-jliff)

dF: Type is indidcated on line 4.

Robert:  Some things are not showing, such as “jliff-version”

dF: Can you please update the examples?

Robert: Yes

Phil: The different root implement a common interface which is minimal.  The other mechanism was to have property names which was in the root of the file.

Chase: Is this different than what is in the spec?

dF:  I think we can show this at the conference next month as the minimum viable product.  I also think it’s time to make design decisions.

Following the OM discussion and the JLIFF capability to represent fragments from different logical levels

Consensus: JLIFF objects and arrays will be always wrapped with a top level object (thus necessarily nameless) indicating jliff version and other global properties of the fragment. 

What can be inside / what is valid JLIFF content? :

files   --- the top level object corresponds to XLIFF

groups | units --- the top level object corresponds to file

subunits --- the top level object corresponds to unit

Issue: if content is units what's the corresponding XLIFF level? Could be group and could be file. This has potential to break roundtrip..

- what has to be on the wrapper level? 

list: JLIFF version srcLang / trgLang ...srcDir / trgDir more?

- Continue discussion on qualified names

Possible prefixes? 

underscore "_" 

colon ":"

dolar sign "$"

dF:  What is our approach to namespaces?  Did anyone have a chance to experiment with namespaces in JLIFF?

Phil,Chase: Not yet.

dF: I think that MDA is the most suitable because it has Key-Value pair structure.

dF: Do we want to make a provisional decision that we go with the JSON LD mechanism for shortening names?

Robert: I second that.  JSON-LD will be a good candidate for allowing us to integrate namespaces.  I think we need to make a plan, next meeting, can we discuss JSON-LD in more detail?

dF: I think for the next meeting we need an example of using JSON-LD. Also, I don’t remember consensus with a specific separator.  We were undecided between “:” and “_”.  “:” maybe looks too XML-ish.

dF:  Both “_” and “:” appear in IRIs.  We can make sure that the appearance of them is separated since we have control over the registered prefixes, so we can make sure that the first "_" or ":" is the separator.

Chase: I’m partial to the “:”.  “:” seems like a markup language component while “_” feels more like programming syntax.

dF: “_” may look forced, like we are deliberately avoiding looking like XML.

Yves:  I actually did a lot with namespaces, using “_” in the last experiment, but “:” should be fine.

Robert: both are aloowed in JSON names, “:” is the separator in JSON-LD names.  I am in favor of going in that direction. 

dF:

- Look at JSON-LD, Use of context, no namespaces, but a way to shorten IRIs

Need to look into a prefix registration mechanism preferably indepnedent on the XLLIFF TC SVN? 

The group consenus seems tending to identification of context for modules and registered extensions.

dF: Yves, in your experiments, were you using explicit context, or were you assuming context in a registry or something?

Yves: I was mostly working with the module, assuming that the prefix was known [i.e. implicit context].

dF: So you were not using explicit context?

Yves: Not at this point, no.

dF: it seems an advantage to not using explicit is that file size gets large when it is used.

dF: Do we want to make a decision on this?

Chase: For some use cases the fully qualified JSON names have potentially a lot of overhead.  I am not certain whether we should support both or only one.  It seems like having the short-form is good sometimes.

dF: There is an article about XML vs. JSON that the implementers should read (https://www.linkedin.com/pulse/horses-courses-perspective-xml-vs-json-discussion-ken-holman/)

dF: He makes the point about XML being globally unambiguous.  He has some good thoughts about using the fully qualified context and shorthand.  XML is much more audit friendly than JSON.  It seems it depends on use cases, as Chase mentioned.

dF: I don’t feel we are able to make a decision at this point.

dF: Any other JLIFF questions we need to pursue? [no response]

- Using XLIFF 2 test suite to test JLIFF expressivity

wait for XLIFF 2.1 test suite

Soroush? status?

There will be new extraction /merge example by Moravia, should appear either on XLIFF SVN or TAPICC GitHub..

3- TBX Mapping

Report from editorial 1-2-1 meeting [skipping until TC 37 meetings in Vienna late June]

current editor's draft: https://tools.oasis-open.org/version-control/browse/wsvn/xliff-omos/trunk/XLIFF-TBX/xliff-tbx-v1.0.pdf

Vienna aftermath report (dF/James)

dF:  We are waiting for the ISO standard to be technically stable. 

James, the new TBX should be modular, unfortunately unclear about namespaces.

Namespaces will probably prevail but not sure if a namespace will be for the extension or for the whole dialect-vocabulary..

C- Otherr Topics

2- Liaisons

Where to place work on extraction reference guides? Seems industry want that..

Proposed that as TAPICC track inside Strand 1 Supply Chain Automation. WG3

GALA TAPICC https://www.gala-global.org/tapicc-translation-api-class-and-cases-initiative

TAPICC does not require GALA Membership. OMOS object model is linked to 2nd and 3rd Tracks of TAPICC.

Chase: TAPICC has a very aggressive goal to produce by the end of the year.  What does this mean for us?

dF: All current Working Groups are in Track 1, so they are not dependent on our progress, they use just the XLIFF original XML.  Next year we can try to launch the second and third tracks.  Probablz at FALA Boston 2018. This could be a motivation for us to have something prepared (testable, workable, presentable) for this.  It should be feature-complete for those features which we choose (not necessarily everything), by next March.  How is that?

Robert? (not sure): Possible..

dF: Possible is good!

dF: Ballot on cs01 will start soon.. We have collectied enough statements of use to progress with the standard.  So XLIFF 2.1 should be in candidate OASIS status in two weeks or so...

3- Promotion

FEISGILTT / XLIFF / JLIFF Symposium schedule published

https://locworld.com/wp-content/uploads/2017/10/FEISGILTT2017Program.pdf

Registration open

https://locworld.com/events/feisgiltt2017/

4- AOB

1- Date of next meeting

2- Looking for a new secretary. Contact dF

dF: We will probably send out a Doodle to decide on a date.  We also still need a secretary (or even a co-chair) so someone can host meetings, maintain the roster, and such.  We mostly need a stable backup for chairing.  Please contact me if you are interested.

dF: We are skipping Oct. 24th.  Do the other dates (10 Oct, 14th Nov, 28th Nov, 12th Dec)  sound good? [yes]

dF: meeting adjourned

A. Admin

1- Roll call

7 Voters total

2- Minutes from the last quorum meeting  2017-07-23

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

B. Material

1- XLIFF OM

(https://github.com/oasis-tcs/xliff-omos-om)

check the wiki mapping

https://github.com/oasis-tcs/xliff-omos-om/wiki

JLIFF unlike XLIFF has the capability to represent fragments at different logical levels -> need for a wrapper object in JLIFF at the top level

- what has to be on the logical root level?

list: srcLang / trgLang ...srcDir / trgDir .. whitespace handling (how?) more?

2- JLIFF

(https://github.com/oasis-tcs/xliff-omos-jliff)

Following the OM discussion and the JLIFF capability to represent fragments from different logical levels

Consensus: JLIFF objects and arrays will be always wrapped with a top level object (thus necessarily nameless) indicating jliff version and other global properties of the fragment. 

What can be inside / what is valid JLIFF content? :

files   --- the top level object corresponds to XLIFF

groups | units --- the top level object corresponds to file

subunits --- the top level object corresponds to file

Issue: if content is units what's the corresponding XLIFF level? Could be group and could be file. This has potential to break roundtrip..

- what has to be on the wrapper level? 

list: JLIFF version srcLang / trgLang ...srcDir / trgDir more?

In jliff the root object has no name and carries the global information such as jliff version.

AI:

To create JLIFF examples with each possible root.

- Continue discussion on qualified names

Possible prefixes? 

underscore "_" 

colon ":"

dolar sign "$"

- Look at JSON-LD? Use of context, no namespaces, but a way to shorten IRIs

Need to look into a prefix registration mechanism preferably indepnedent on the XLLIFF TC SVN? 

The group consenus seems tending to identification of context for modules and registered extensions.

We can control via the registration mechanism that the first _ or : or $ or whatver the consenus is the separator of the qualifier.

Note that this leads to top level "pseudoobject" defining that context that JSON theorists don't seem to like. But we need that the capture the logical top level anyways.

- Using XLIFF 2 test suite to test JLIFF expressivity

wait for XLIFF 2.1 test suite

Soroush? status?

Ján Husarčík will submit new samples this week

3- TBX Mapping

Report from editorial 1-2-1 meeting [skipping until TC 37 meetings in Vienna late June]

current editor's draft: https://tools.oasis-open.org/version-control/browse/wsvn/xliff-omos/trunk/XLIFF-TBX/xliff-tbx-v1.0.pdf

Vienna aftermath report (dF/James)

TBX had good meeting in Vienna, strong consensus allowing for modernization of industry relevant profiles of TBX. 

C- Otherr Topics

2- Liaisons

Where to place work on extraction reference guides? Seems industry want that..

Proposed that as TAPICC track inside Strand 1 Supply Chain Automation

GALA TAPICC https://www.gala-global.org/tapicc-translation-api-class-and-cases-initiative

TAPICC does not require GALA Membership. OMOS object model is linked to 2nd and 3rd tracks of TAPICC.

XLIFF TC - XLIFF Version 2.1 will progress to cos01

3- Promotion

8th XLIFF Symposium CFP has been extended

The main conference is Nov 1-Nov 3, FEISGILTT will be held on Oct 31-Nov 1, 2017. Save the dates.

https://locworld.com/events/feisgiltt2017/

4- AOB

1- Date of next meeting

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

26th Sep, 10th Oct, 14th Nov, 28th Nov, 12th Dec. Which brings us to the end of 2017.

So that means I am also looking into a volunteer to chair 24th Oct, where I will be at tcworld Stuttgart and again unable to chair.

2- 

Both OMOS Secretaries had resigned at this point, so I am looking into volunteers for the secretary role.

Also we are looking into a backup maintainer for the OM Github repo

• OASIS Open (General Membership)
• General Public