OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-omos message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Modified: 4th Tuesday - Regular XLIFF OMOS TC telecenference


Submitter's message
Added minutes.. Thanks to Phil for scribing
dF
-- Dr. David Filip
Event Title: 4th Tuesday - Regular XLIFF OMOS TC telecenference

Date: Tuesday, 24 April 2018, 05:00pm to 06:00pm WEST
Location: https://www.oasis-open.org/apps/org/workgroup/xliff-omos/members/action_item.php?action_item_id=3822
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


This meeting counts towards voter eligibility.

Agenda

A. Admin

1- Roll call

? out of 5 voters

aprove minutes from 10th April 2018

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

 

B. Material

1- XLIFF OM

OM wiki needs aligned with current JLIFF structure as per 0.9.5

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 targeting 24th April, good chance to complete by then.

Robert seeks gudance on ITS module

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.

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

4- AOB

1- Date of next meeting

8th May Cancelled,

22nd May

2- Looking for a new secretary. Contact dF


Minutes

OMOS 2018-04-24
Attendees: robert, david, phil (minutes), steven Apologies: yves
Approve minutes of last meeting
rve seconded minutes
1. jliff changes
rve: commit b43755 schema 0.9.6 ...pc, mrk and cp were added but are not needed. ...Format Style and validation modules added ...consistently use plural forms for arrays ...match to matches ...metadata is one word so no camel case (metaData) ...everything is there except for ITS ...pc, mrk and cp were added just so there was a version which mirrors XML ...that way I don't forget to model something ...limited ability to add notes to json schema
df: we need to start the prose of the specification to capture some decisions and reasons ...I already started the prose for the object model but it is out of date ...please keep track of things in the wiki
rve: the wiki needs a tidy up
df: at this point we have a one-to-one copy of XLIFF 2.0 ...<ph/> should be in jliff ...<pc/> is pair of <ec/><sc/>, so no need for <pc> and also no need for <mrk> and <cp>. Early concensus not use those as XMLisms.
rve: I agree pc are xml specific but nothing to stop us having them in jliff ...syntax-wise not needed but perhaps from a semantic perspective?
df: cp is not needed in jliff
rve: happy as long as semantics can be preserved ...cp semantics would be lost during round trip ...I'll make a note in the schema
sl: we have done transformations from LDML to json ...when we go to json we flatten out some things ...ldml made a decision to never have mixed text and entity values in the schema
df: XLIFF 2 as weel, in 2.0 and 2,1 (and on) original data is stored on unit level outside of the inline data model.
sl: LDML also abandoned using cp and switched to CDATA section for content that has complex syntax
df: if you ignore cp you'll loose it
sl: json escaping rules should be able to cope with 
rve: in json there are just escapes for quotes
sl: we need good examples of xliff converted to jliff and the other way around
rve: let me add notes to the schema and the wiki
2. ITS
rve: the difference I perceieve for ITS ...ITS is quite unclear how to mesh with json content ...how do we approach it?
df: think of ITS as a number of modules ...it is originally a W3C spec ...intended for native content formats ...it is a metadata format ...in xliff it can annotate source, target and structure ...5.9.6 are features not existing in xliff ...but in 5.9.7 there is partial overlap with xliff features ...5.9.8 are metadata categories we probably don't need to care for in JLIFF
sl: we've used jsonpath to some extent ...incompatible specifications and implementations
df: 5.9.9 can be ignored ...they are not represented in the serialization ...you probably need to look at 5.9.5 [ITS tools referencing orthogonal to the rest of the ITS Module], 5.9.6 and 5.9.7 as if each is an individual module ...inline only can just be applied to <sm/> ...structural is another matter
rve: okay then we'll explicityly add properties to unit, group and sm ...I'll give it a shot
df: please create 0.9.7 version of JLIFF schema without pc, mrk and cp ...then you're done with xliff 2.0 ...then create a branch for 2.1 weher u can start adding ITS
rve: I'll create two sub-directories in the branch ...will we call them jliff 2.0 and 2.1
df: yes, I think so
rve: modules are built-in ...for extensions it makes sense
df: we want them recognisable as modules but not using fully qualified names
rve: you can't have both
df: we can look into another sort of separator, maybe an underscore "_"..


3. Next meeting is 22/5/2018



Owner: Dr. David Filip
Group: OASIS XLIFF Object Model and Other Serializations (XLIFF OMOS) TC
Sharing: This event is shared with the OASIS Open (General Membership), and General Public groups. Public Event Link
  • Learn more about subscribing here.
  • View the OASIS XLIFF Object Model and Other Serializations (XLIFF OMOS) TC calendar here.
  • You may receive future notifications with updates to this event. Update the event on your calendar by accepting the changes.

Attachment: ical_41683.ics
Description: application/ics

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
METHOD:REQUEST
VERSION:2.0
PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VTIMEZONE
TZID:Europe/Lisbon
BEGIN:STANDARD
DTSTART:20001029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:WET
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T010000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:WEST
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
STATUS:CONFIRMED
TRANSP:OPAQUE
DTSTAMP:20180522T145716Z
DTSTART;VALUE=DATE-TIME;TZID=Europe/Lisbon:20180424T170000
DTEND;VALUE=DATE-TIME;TZID=Europe/Lisbon:20180424T180000
SEQUENCE:14
SUMMARY:4th Tuesday - Regular XLIFF OMOS TC telecenference
LOCATION:https://www.oasis-open.org/apps/org/workgroup/xliff-omos/mem
 bers/action_item.php?action_item_id=3822
LAST-MODIFIED:20180522T145716Z
ORGANIZER:workgroup_mailer@lists.oasis-open.org
ATTENDEE;CUTYPE=GROUP:MAILTO:xliff-omos@lists.oasis-open.org
DESCRIPTION:See the private action item for dial in details\n\nhttps://w
 ww.oasis-open.org/apps/org/workgroup/xliff-omos/members/acti
 on_item.php?action_item_id=3822\n\nAgenda: A. Admin\n\n1- Ro
 ll call\n\n? out of 5 voters\n\naprove minutes from 10th Apr
 il 2018\n\nhttps://www.oasis-open.org/apps/org/workgroup/xli
 ff-omos/email/archives/201804/msg00004.html\n\n \n\nB. Mater
 ial\n\n1- XLIFF OM\n\nOM wiki needs aligned with current JLI
 FF structure as per 0.9.5\n\nhttps://github.com/oasis-tcs/xl
 iff-omos-om/wiki\n\n \n\n2- JLIFF\n\n(https://github.com/oas
 is-tcs/xliff-omos-jliff)\n\nConsensus on boolean vs a yes/no
  enumeration restated:\n\nStick with yes/no enumeration becu
 ase boolean default is false\, while XLIFF defaults are yes.
  \n\nACTION ITEM: [pending]\n\nDavid-&gt\; Email the working
  list about keeping yes|no strings (according to the discuss
 ion today) and hearing Phil&rsquo\;s perspective as well as 
 others.\n\n \n\nAI Robert\n\nExpress all XLIFF 2.1 and 2.0 m
 odules in JLIFF schema. Have 2.1 and 2.0 branches\n\n*[Revie
 w progress]*\n\nRobert targeting 24th April\, good chance to
  complete by then.\n\nRobert seeks gudance on ITS module\n\n
 Previous Consensus: restated\n\nWe agreed to work on 2.1 bra
 nch first and only then fork the 2.0\n\nDON&#39\;T reference
  the context file [for core and module] from schema or insta
 nces. This is tied via the spec [driven by version number] b
 ut not the instances\, to prevent hammering of the context f
 ile.\n\nExtensions always need to declare or reference their
  context inline.\n\nAI Robert [DONE]\, implement meeting con
 senus for extension points. Extension data needs to start wi
 th context. Each extension will be one object. Try to allow 
 them only where they&#39\;re allowed in XLIFF\n\nreviewed &q
 uot\;element&quot\; extension points implemented as has map 
 rather than an array in the latest commit https://github.com
 /oasis-tcs/xliff-omos-jliff/commit/85e7c3e0e8d88539df5b2eb75
 19d6735f84256e9\n\nConsensus restated::\n\nDon&#39\;t use ex
 ternal context for extensions.\n\nAll extension context must
  be stated inline to avoid parsing external context files..\
 n\nWe also agreed that having a dedicated extension containe
 r is more validation friendly than just allowing additional 
 properties on the root structure..\n\n-Continue discussing p
 ros and cons of the extensionsData approach\n\ncompare with 
 XML and consider going back and forth between XML and JSON.\
 n\n \n\n3- TBX Mapping\n\nTBX-Basic mapping is in order\, al
 most done on TBXInfo\n\nUpdate from James?\n\nC- Other Topic
 s\n\n \n\n3- Promotion\n\nAlso Phil JLIFF library open sourc
 ing was announced in the GALA week \n\nhttps://twitter.com/V
 istatecGlobal/status/974538466565373952\n\nhttps://twitter.c
 om/merzbauer/status/974288543093854208\n\nGALA TAPICC needs 
 to work on launching JLIFF based Track 2\n\n4- AOB\n\n1- Dat
 e of next meeting\n\n8th May Cancelled\,\n\n22nd May\n\n2- L
 ooking for a new secretary. Contact dF\nGroup: OASIS XLIFF O
 bject Model and Other Serializations (XLIFF OMOS) TC\nCreato
 r: Dr. David Filip
URL:https://www.oasis-open.org/apps/org/workgroup/xliff-omos/event.php?event_id=41683
UID:https://www.oasis-open.org/apps/org/workgroup/xliff-omos/event.php?event_id=41683
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT00H15M00S
END:VALARM
END:VEVENT
END:VCALENDAR


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]