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

OMOS Meeting 2017-07-23
Roll call:
David, Chase, Phil (minutes), Robert, Soroush,

Quorum achived with 5 out of 8 voters.

Minutes from the last quorum meeting June 13th  2017

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

Robert seconded

approved by consenus

dF:
In jliff the root object has no name and carries the global information such as jliff version.
Schema and samples updated to 0.9.4.
dF: It would be good to create example of a fragment that represent different OM root levels.
rve: Which entities should be presumed possible roots?
df: Whenever in abstract model wiki

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

there is square bracket saying it, it is a possible root. ...
rve: The proposal is to create examples with each possible root.
df: yes, and allow it in schema, the advantage of jliff is anonymous wrpapper and different roots. ... I think there's an issue ... The top level can be files but not smaller than Unit. ...because it is teh smallest logical unit ...Then If we have only units inside then we don't know what it corresponds to in xliff, it could be a group [a possible root] or file [another possible root]
ct: There's no equivalent ...in xliff there's no similar structural concept. ...I'm not sure there's a use case ...what does teh round trip need to guarantee?
df: interoperability is now the issue. I have a jliff of units but I'm not sure if it's a group or file. ...we would not allow to represent groups or units but not both ...I think we should introduce a property on the wrapper telling you what the context of the jliff is. ...right now wrapper only has versiion, source and target languages.
rve: the wrapper could contain alternative roots
df: I want to get a list of what any possible root object needs, it should carry all globa info that in XLIFF is inherited from higher levels. ...srcLang, trgLang, version, whitespace (jliff always preserves and we agreed not to encode this assumption), srcDir, trgDir, group="yes|no" [this would be an indicatorm what's the root in case of units content]
rve: if interoperability is required the would a more one-to-one representation not be required?
df: If the content of jliff is units you cannot tell what level of xliff has been extracted. ...this is why we need a property to help identification
rve: what if we have a fragment property? ...we can add property names and then not need additional metadata ...I can give this a try
df: sounds good.
df: we need to come back to the context as well which defines the namespaces, this is another type of data that needs to live on the wrapper level
rve: I see pros and cons of json-ld ...the specification is quite large and we'd only be using a small subset, the IRI compacting
df: i would be in favour of explicit context
rve: we can use json-ld to bind the fully qualified iri's ...if we use json-ld do we then have to support eveyhtjing or then not be json-ld compliant ...xml standards are nicely compartmentalized and you can choose which to implement and be compliant with ...we should preferably have an explicit context ...we should use 6.3 for our purposes
df: we should allow different types of root.
pr: I did update my .NET code to 0.9.4 
phil and chase plan to come to the symposium.
df: coming is good but u should also consider speaking ;-) https://locworld.com/events/feisgiltt2017/ ...TBX had good meeting in Vienna, strong consensus allowing for modernization of industry relevant profiles of TBX. TAPICC will be strongly represented on FEISGILTT Silicon Valley..

Meeting adjourned

A. Admin

1- Roll call

8 Voters total

2- Minutes from the last quorum meeting June 13th  2017

https://www.oasis-open.org/apps/org/workgroup/xliff-omos/email/archives/201707/msg00002.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?

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

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)

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.

TBX Steering Committee / ISO TC37/SC3 - preparation for June meeting in Vienna / Call for XML experts

Possible TBX modernization

XLIFF TC - 4th public review started on 5th June

https://www.oasis-open.org/news/announcements/invitation-to-comment-on-xliff-v2-1-ends-june-20th

http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd04/xliff-core-v2.1-csprd04.html

Work on cs01 underay, possibly csprd05

3- Promotion

8th XLIFF Symposium CFP has been extended

http://bit.ly/XOMOSAn

spread the word, consider speaking

The main conference is Nov 1-Nov 3, FEISGILTT will be held on Oct 31-Nov 1, 2017. Save the dates. Submit a paper, recruit speakers, volunteer for the PCs.

4- AOB

1- Date of next meeting

Doodle for the summer closed

https://doodle.com/poll/grchwua93254m49g

The rest of this summer seems fine.

Need another chair person for  Sep 12, as dF will be on JTC1 SC38 plenary

2- Looking for a new secretary. Contact dF

• OASIS Open (General Membership)
• General Public