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
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
==========
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]
==========
Attendance:
| Meeting Statistics |
| Quorum rule |
51% of voting members
|
| Achieved quorum |
yes |
| Individual Attendance |
Contributing Members: 4 of 20 (20%)
Voting Members: 4 of 6 (66%) (used for quorum calculation)
|
| Company Attendance |
Contributing Companies: 4 of 15 (26%)
Voting Companies: 4 of 6 (66%)
|