< Return to Calendar

* 2nd Tuesday - Regular XLIFF OMOS TC telecenference (Conference Call) (Conference Call)
Name * 2nd Tuesday - Regular XLIFF OMOS TC telecenference (Conference Call) (Conference Call)
Time Tuesday, 14 November 2017, 05:00pm to 06:00pm WET
(Tuesday, 14 November 2017, 05:00pm to 06:00pm UTC)
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

Minutes

OMOS Minutes 2017-11-14

phil (minutes), robert, david, yves

Last minutes

http://markmail.org/thread/d75nrfa4bjegfrta

approval seconded by Yves.

1. XLIFF OMOS 

df started prose on definitons. It is WIP branch on the GitHub repo, not merged back into master yet..

https://github.com/oasis-tcs/xliff-omos-om/commit/7f91ae591dfbe685adad816cf6893ee945b9d933

2. JLIFF 

Content types

rve's email on this thread

http://markmail.org/thread/75n3r6sxrbzohgkk

 

df: Don't want to have content type as an attribute.
...currently subunits and files
...groups and units are wrong, we need subfiles and subgroups, both have the same data model and can mix objects of type group and unit

rve: ok I will go ahead and implement as per email of 23rd
...groups and units as arrays
...array containing a mix of groups and units?

df: yes

rve: we dont have a defintion of groups or subgroups
...must be an oversight

rve: unit has subunit
...we may have combined information into subunit

df: group purpose is just grouping

rve: in json difficult to distinguish two types of object
...unit from group will require type property

df: 
jliff
----files [of file]
    ----subfiles|subgroups [of group or unit]
        ...
        subunits [of segment or ignorable]


pr: so then group and unit objects must have type properties

ys: an array of subfiles would be subfile and subgroups?
...I'm lost sorry

rve: same as subunit being segment or ignorable

df: repeat exactly for subgroups and subfiles
...just to know where we are in the object model

df: subunit and subfile are abstractions, union of segment and ignorable and group and unit respectively, they are choice groups in the XML grammars, oneOf in JSON schema
...we need an example
...we met in Silicon Valley and discussed that we need to the root type properties
...to facilitate exchange 
...we are now on a better track with plural properties (arrays)
...Chase as far as I know did not make the context file, hopefully he is going to join us..

rve: we are using json-ld to capture namespaces

WRT the unsuported modules discussion http://markmail.org/thread/dw3equt7ae57h6xb


...i did not understand why there could be a clash

ys: my issue is: there will be times we don't know the represretation in JLIFF
...tools that know about the module could convert a string into the object.. but tools that don't couldn't
...JSON requires typing but in XML nothing is typed w/o a schema

ys: making the distinction between supported and unsupported modules

df: I'm afraid we will have to be more demanding in case of crossing the XLIFF/JLIFF boundary

ys: there's no thing such as unsupported module?
...one big aspect of xliff is you could have unsupported modules

df: sure, and we can have unsuported modules in JLIFF 2, once they were written once by a tool knowing the typing information..

We will probably need to introduce a new agent type, a tool that converts from XLIFF to JLIFF must know at least about schemas of the modules to be able to write them in JLIFF..
...what about other technologies, is it common tha they require typing in order to write?
...what about protobuf?

ys: I don't know enough about protobuf

df: yaml?

rve: yaml is getting more popular
...not sure how practical it would be
...target technology should have an accompanying schema language.. JSON schema is in WIP, schema/grammar methods don't exist for many technologies

df: quite common in oasis to do yaml representations, will need to look into it..

rve: yaml similar to json with hiearchies
...json only has string or numbers
...cannot define whitespace
...could use regular expressions
...or just stick to builtin types

df: uri or iri type?

rve: you can define email as regex
...regex could define nmtoken

df: first priority to define structure
...I think we have to have them [patterns for iris, NMTOKEN etc.]
...nmtoken is not defined in uml, that's why it's currently not captured in the model on the om REPO

Registration
df: I did not bring up at last xliff tc
...ys looks after the XLIFF TC process for registrating prefixes
..."must not contain colon" should be in requirements of the registration process
...agreed separator is colon ":"

ys: yes, this is good requirement, would be an issue in XLIFF too

TAPICC
https://github.com/GALAglobal/TAPICC/tree/master/extraction_examples

best practice document along those examples in progress

 

df: March 2018 is target for jliff 1.0
...FEISGILTT happened and Chase presented jliff work

df: XLIFF 2.1 COS01 review still open 

until 19th December 2017

http://bit.ly/XLIFF21COS01


...Next meeting 28 November, then 12 Dec,
...then 9 January 2018

Did not run the Doodle as it was obvius we have to skip 26th Dec. 12th Dec and 9 Jan are normal dates..

Does 9th Jan look good in general?

pr: too far in the future

[meeting adjourned]



Agenda

A. Admin

1- Roll call

x out 6 Voters total

aprove minutes from 10th Oct 2017

http://markmail.org/thread/d75nrfa4bjegfrta

 

B. Material

1- XLIFF OM

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

dF made some progress on prose

 

discussion on unsuported modules and extensions

http://markmail.org/thread/dw3equt7ae57h6xb

relevant for both OM and JLIFF

 

2- JLIFF

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

AI Chase: commit the context file

AI Robert:  

make the schema reference the context file

make content (root) type keep information about XLIFF level of content,

see dsicussion of "root types"

http://markmail.org/thread/75n3r6sxrbzohgkk

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

 

-  qualified names (URI shortening)

Agreed separator:

colon ":"

 

New Extraction / Merge examples via TAPICC

https://github.com/GALAglobal/TAPICC/tree/master/extraction_examples

 

3- TBX Mapping

Report from editorial 1-2-1 meeting [skipping until January 2018]

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

Is it time to resume work on the TBX Basic mapping?

C- Other 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

Traget to provide technically stable JLIFF 1.0 by GALA Boston March 2018.

XLIFF Version 2.1 COS01 review until 19th December 2017

http://bit.ly/XLIFF21COS01

 

 

3- Promotion

FEISGILTT / XLIFF / JLIFF Symposium took place

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

4- AOB

1- Date of next meeting

28th Nov, 12th Dec, [skip Dec 26], 9th Jan 2018 and so on..

did not run Doodle for holiday season.. not needed

2- Looking for a new secretary. Contact dF



Submitter Dr. David Filip
GroupOASIS XLIFF Object Model and Other Serializations (XLIFF OMOS) TC
Access This event is visible to OASIS XLIFF Object Model and Other Serializations (XLIFF OMOS) TC and shared with
  • OASIS Open (General Membership)
  • General Public