< Return to Calendar

* 4th Tuesday - Regular XLIFF OMOS TC telecenference (Conference Call)
Name * 4th Tuesday - Regular XLIFF OMOS TC telecenference (Conference Call)
Time Tuesday, 22 May 2018, 05:00pm to 06:00pm WEST
(Tuesday, 22 May 2018, 04:00pm to 05: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

Agenda
A. Admin
1- Roll call
? out of 5 voters
aprove minutes from 24th April 2018
https://www.oasis-open.org/apps/org/workgroup/xliff-omos/email/archives/201805/msg00003.html

Attending:  2 of 5 voters
Voting Members:
David Filip, Robert Van Engelen
Non-Voting Members:
James Hayes


B. Material
1- XLIFF OM
OM wiki needs aligned with current JLIFF structure as per 0.9.7
https://github.com/oasis-tcs/xliff-omos-om/wiki
 
2- JLIFF
(https://github.com/oasis-tcs/xliff-omos-jliff)
Consensus on boolean vs a yes/no enumeration restated:
Stick with yes/no enumeration becuase boolean default is false, while XLIFF defaults are yes. 
ACTION ITEM: [pending]
David-> Email the working list about keeping yes|no strings (according to the discussion today) and hearing Phil’s perspective as well as others.
David: For ITS, I propose we use a different separator, perhaps “_”, but it looks like you are using “-“, which could be could for compatibility with XML.
Robert: “_” is perhaps more code friendly.
David:  I think it makes sense not to require the qualifications for the modules.  I’m in favor of having a different separator, but I’m fine with either “_” or “-“
Robert: I think it is a lot more usable to only use JSON LD for extensions.  
Robert: If this grammar is linear it can be cast into a pattern, which can be described in JSON schema to only restrain this char class to permitted values.  The grammar should be linear but I’m not sure.
REFERENCE: https://www.w3.org/TR/its20/#allowedchars
Robert: With ITSM, I will strip the itsm: prefix.
David: I think we will want to use the itsm_ type prefixes throughout
Robert:  Locale Filter is a relatively straightforward change. 
David: it is basically not allowed on structural.  If you want it you have to put it inline.  So that means it’s just on sm


Robert: LocQualityIssue all seem to be on sm.
David:  These look good. Is there a standoff element?  I think the role of the ref is to point to the standoff element.
David:  I guess you will have the same issues as XML, so that is probably good.  You just need to implement standoff.

David: Provenance Record is a standoff element.  Localisation issues is an array of issues, and provenance array is an array of records.  It looks big, but it is fairly simple.  
Robert: Ok, that will be something I will work on next.

David:  5.9.8 and 5.9.9 ITS should be out of scope for JLIFF.  5.9.7 will have a partial overlap so needs to be done.  We can skip 5.9.7.1

JLIFF ITS Progress file contents:
5.9.5 ITS Tools Annotation:  missing
---------------
5.9.6.1 Allowed Characters: done
5.9.6.2 Domain: not done
5.9.6.3 Locale Filter: done
5.9.6.4 Localization Quality Issue: done for inline, standoff pending
5.9.6.5 Localization Quality Rating: done
5.9.6.6 Provenance: not done
5.9.6.7 Text Analysis: not done
5.9.7 partial overlap – TODO
5.9.8 no impact on JLIFF
5.9.9 no impact on JLIFF

David: 5.9.7.3 You need to allow xml:lang inline on <sm>
David: 5.9.7.4 MT Confidence must be used with annotator. Before you go for term and MT Confidence, to Tools Annotation 5.9.5 because you will need them.
David: I think that’s enough for now.
Robert: What I’ll do is start with Provenance and Tools Annotation after.  Then Domain as the third thing.
David: 5.9.7.5 is just an extension mechanism on storage size, so we already have it.

 

 

 

AI Robert
Express all XLIFF 2.1 and 2.0 modules in JLIFF schema. Have 2.1 and 2.0 branches
*[Review progress]*
Robert seeked gudance on ITS module, given on 24th April
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.
Do we need to use a different separator for modules? underscore "_"?
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
Consensus restated::
Don't use external context for extensions.
All extension context must be stated inline to avoid parsing external context files..
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 from James?
C- Other Topics
 James: I added normative references and gave definitions for TBX agents.  I still need to add an introduction
David:  Ok.  I think we are making good progress on this.

3- Promotion
Also Phil JLIFF library open sourcing was announced in the GALA week 
https://twitter.com/VistatecGlobal/status/974538466565373952
https://twitter.com/merzbauer/status/974288543093854208
GALA TAPICC needs to work on launching JLIFF based Track 2
Will probably launch by end of June
4- AOB
1- Date of next meeting
12th June 2018
2- Looking for a new secretary. Contact dF
David: James, would you be willing to be secretary?
James: Sure, I can handle that.
David:  Is there any dissent from you Robert?
Robert: No dissent.



Agenda

A. Admin

1- Roll call

? out of 5 voters

aprove minutes from 24th April 2018

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

 

B. Material

1- XLIFF OM

OM wiki needs aligned with current JLIFF structure as per 0.9.7

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

 

2- JLIFF

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

Consensus on boolean vs a yes/no enumeration restated:

Stick with yes/no enumeration becuase boolean default is false, while XLIFF defaults are yes. 

ACTION ITEM: [pending]

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 seeked gudance on ITS module, given on 24th April

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.

Do we need to use a different separator for modules? underscore "_"?

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

Consensus restated::

Don't use external context for extensions.

All extension context must be stated inline to avoid parsing external context files..

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

C- Other Topics

 

3- Promotion

Also Phil JLIFF library open sourcing was announced in the GALA week 

https://twitter.com/VistatecGlobal/status/974538466565373952

https://twitter.com/merzbauer/status/974288543093854208

GALA TAPICC needs to work on launching JLIFF based Track 2

Will probably launch by end of June

4- AOB

1- Date of next meeting

12th June 2018

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