[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Modified: Exceptional 5th Tuesday XLIFF OMOS meeting
Event Title: Exceptional 5th Tuesday XLIFF OMOS meeting Date: Tuesday, 30 January 2018, 05:00pm to 06:00pm WET 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 RSVP This meeting counts towards voter eligibility. Agenda Agenda
A. Admin 1- Roll call aprove/ammend minutes from 23rd Jan 2018 https://www.oasis-open.org/apps/org/workgroup/xliff-omos/email/archives/201801/msg00003.html B. Material 1- XLIFF OM In connection with finalizing the JLIFF structure with recursive subroups, dF modified the OM wiki https://github.com/oasis-tcs/xliff-omos-om/wiki See AI Robert to implement this in JLIFF schema 2- JLIFF (https://github.com/oasis-tcs/xliff-omos-jliff) Previous Consensus: restated 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. [WIP, extension points?] AI Robert [WIP]: restated we have a good structure now, we just need to add subgroups as per previous minutes subgroups type is the same as subfiles, both subgroups and a subfiles are arrays of oneOf group and unit objects see discussion of "root types" http://markmail.org/thread/75n3r6sxrbzohgkk AI Chase [pending]: Chase temporarily out, need to fork the context files make context for 2.0 and 2.1 AI Robert, 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 - Continue discussion on extension points, look at Robert's commit to introduce extension https://github.com/oasis-tcs/xliff-omos-jliff/commit/85e7c3e0e8d88539df5b2eb7519d6735f84256e9 There are several places where context can be provided: root, or units, files, groups. (Whether @context should be at root or only lower levels). Should mimic XLIFF behavior as close as possible.. 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. AI dF and Yves [pending, dependency in XLIFF TC meeting]: clear usage of XLIFF prefix registration mechanism for JLIFF, request that XLIFF prefixes don't use colon ":" raised on XLIFF TC 16th Jan DONE in principle, some minor fixes pending http://markmail.org/thread/qmvyp4yuihx76g6r
3- TBX Mapping TBX-Basic mapping is in order, almost done on TBXInfo @James, would you share the dev page, or is it released yet? C- Other Topics 2- Liaisons XLIFF 2.1 had to go for COS02, https://www.oasis-open.org/committees/ballot.php?id=3166 Special majority ballot closes tomorrow. Then a two weeks OASIS call for Consent. 3- Promotion Will have good coverage on GALA Boston in March, as TAPICC Track 2 will be launched, building on JLIFF 4- AOB 1- Date of next meeting Should consider 30 Jan (5th Tue), 13th Feb and 27th Feb look good 2- Looking for a new secretary. Contact dF
A. Admin 1- Roll call ? out of 5 voters aprove minutes from 9th Jan 2018 http://markmail.org/thread/ohzqaonhfdvqenml approved by CFD B. Material 1- XLIFF OM In connection with finalizing the JLIFF structure with recursive subroups, dF modified the OM wiki https://github.com/oasis-tcs/xliff-omos-om/wiki See AI Robert to implement this in JLIFF schema 2- JLIFF (https://github.com/oasis-tcs/xliff-omos-jliff) Previous Consensus: restated 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 Discuss: Use URI type of context or not? AI Robert [DONE]: To be reviewed we have a good structure now, we just need to add subgroups as per previous minutes Robert hesitant to add subgroups for lack of semantic difference. Discussed that offline with Cahse two weeks ago. Chase also thought that subgroups were unnecessary. see discussion of "root types" http://markmail.org/thread/75n3r6sxrbzohgkk The distinction between subgroups and subfiles is important for representing all possible root levels as well as ensuring interoperability, the original design was a property indicating the type of root. But the discussion ensued in the structural proposal that was more automation friendly. In general either the root type property or the strutural difference between subfiles and subgoups are needed to preserve the LIOM fragment level when exchanging between technologies. dF explained the difference between subfiles and subgroups. sublfiles are always top level, while subgroups can be not only in subfiles but also in other subgroups. Robert agreed to implement and document that, so that we don't keep returning to the issue.
make context for 2.0 and 2.1 dF AI to make a PR for forking the 2.0 and 2.1 contexts
- Continue discussion on extension points, look at Robert's commit to introduce extension https://github.com/oasis-tcs/xliff-omos-jliff/commit/85e7c3e0e8d88539df5b2eb7519d6735f84256e9 There are several places where context can be provided: root, or units, files, groups. (Whether @context should be at root or only lower levels). Should mimic XLIFF behavior as close as possible.. 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. AI dF and Yves [DONE]: clear usage of XLIFF prefix registration mechanism for JLIFF, request that XLIFF prefixes don't use colon ":" raised on XLIFF TC 16th Jan DONE in principle, some minor fixes pending, e.g. FAQ http://markmail.org/thread/qmvyp4yuihx76g6r
3- TBX Mapping TBX-Basic mapping is in order, almost done on TBXInfo @James, would you share the dev page, or is it released yet? C- Other Topics 2- Liaisons XLIFF 2.1 had to go for COS02 -> OS Progress 3- Promotion Will have good coverage on GALA Boston in March, as TAPICC Track 2 will be launched, building on JLIFF 4- AOB 1- Date of next meeting 13th Feb and 27th Feb look good
2- Looking for a new secretary. Contact dF
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 Recurrence This event is part of a series with 14 more events. The next 4 events in this series: Friday, 02 March 2018, 05:00pm to 06:00pm WET Friday, 30 March 2018, 05:00pm to 06:00pm WEST Monday, 30 April 2018, 05:00pm to 06:00pm WEST Wednesday, 30 May 2018, 05:00pm to 06:00pm WEST |
Attachment:
ical_47010.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:20180123T182633Z DTSTART;VALUE=DATE-TIME;TZID=Europe/Lisbon:20180130T170000 DTEND;VALUE=DATE-TIME;TZID=Europe/Lisbon:20180130T180000 SEQUENCE:1 SUMMARY:Exceptional 5th Tuesday XLIFF OMOS meeting LOCATION:https://www.oasis-open.org/apps/org/workgroup/xliff-omos/mem bers/action_item.php?action_item_id=3822 LAST-MODIFIED:20180123T182633Z 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: Agenda\n\n \n\n \ n\nA. Admin\n\n1- Roll call\n\naprove/ammend minutes from 23 rd Jan 2018\n\nhttps://www.oasis-open.org/apps/org/workgroup /xliff-omos/email/archives/201801/msg00003.html\n\nB. Materi al\n\n1- XLIFF OM\n\nIn connection with finalizing the JLIFF structure with recursive subroups\, dF modified the OM wiki \n\nhttps://github.com/oasis-tcs/xliff-omos-om/wiki\n\nSee A I Robert to implement this in JLIFF schema\n\n2- JLIFF\n\n(h ttps://github.com/oasis-tcs/xliff-omos-jliff)\n\nPrevious Co nsensus: restated\n\nDON'\;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 instance s\, to prevent hammering of the context file.\n\nExtensions always need to declare or reference their context inline. [W IP\, extension points?]\n\nAI Robert [WIP]: restated\n\nwe have a good structure now\, we just need to add subgroups as per previous minutes\n\nsubgroups type is the same as subfi les\, both subgroups and a subfiles are arrays of oneOf grou p and unit objects\n\nsee discussion of "\;root types&qu ot\;\n\nhttp://markmail.org/thread/75n3r6sxrbzohgkk\n\nAI Ch ase [pending]: Chase temporarily out\, need to fork the cont ext files\n\nmake context for 2.0 and 2.1\n\nAI Robert\, imp lement meeting consenus for extension points. Extension data needs to start with context. Each extension will be one obj ect. Try to allow them only where they'\;re allowed in XL IFF\n\n- Continue discussion on extension points\, look at R obert'\;s commit to introduce extension\n\nhttps://github .com/oasis-tcs/xliff-omos-jliff/commit/85e7c3e0e8d88539df5b2 eb7519d6735f84256e9\n\n There are several places where conte xt can be provided: root\, or units\, files\, groups. \n\n (Whether @context should be at root or only lower levels).\n \nShould mimic XLIFF behavior as close as possible..\n\nWe a lso agreed that having a dedicated extension container is mo re validation friendly than just allowing additional propert ies on the root structure..\n\n-Continue discussing pros and cons of the extensionsData approach\n\ncompare with XML and consider going back and forth between XML and JSON.\n\nAI d F and Yves [pending\, dependency in XLIFF TC meeting]: clear usage of XLIFF prefix registration mechanism for JLIFF\, re quest that XLIFF prefixes don'\;t use colon "\;:" \;\n\nraised on XLIFF TC 16th Jan\n\nDONE in principle\, som e minor fixes pending\n\nhttp://markmail.org/thread/qmvyp4yu ihx76g6r\n\n \n\n3- TBX Mapping\n\nTBX-Basic mapping is in o rder\, almost done on TBXInfo\n\n@James\, would you share th e dev page\, or is it released yet?\n\nC- Other Topics\n\n2- Liaisons\n\nXLIFF 2.1 had to go for COS02\, \n\nhttps://www .oasis-open.org/committees/ballot.php?id=3166\n\nSpecial maj ority ballot closes tomorrow. Then a two weeks OASIS call fo r Consent.\n\n3- Promotion\n\nWill have good coverage on GAL A Boston in March\, as TAPICC Track 2 will be launched\, bui lding on JLIFF\n\n4- AOB\n\n1- Date of next meeting\n\nShoul d consider 30 Jan (5th Tue)\, 13th Feb and 27th Feb look goo d\n\n2- Looking for a new secretary. Contact dF\n\n \n\n\nMi nutes\n\nA. Admin\n\n1- Roll call\n\n? out of 5 voters\n\nap rove minutes from 9th Jan 2018\n\nhttp://markmail.org/thread /ohzqaonhfdvqenml\n\napproved by CFD\n\nB. Material\n\n1- XL IFF OM\n\nIn connection with finalizing the JLIFF structure with recursive subroups\, dF modified the OM wiki\n\nhttps:/ /github.com/oasis-tcs/xliff-omos-om/wiki\n\nSee AI Robert to implement this in JLIFF schema\n\n2- JLIFF\n\n(https://gith ub.com/oasis-tcs/xliff-omos-jliff)\n\nPrevious Consensus: re stated\n\nDON'\;T reference the context file [for core an d module] from schema or instances. This is tied via the spe c [driven by version number] but not the instances\, to prev ent hammering of the context file.\n\nExtensions always need to declare or reference their context inline.\n\nAI Robert [DONE]\, implement meeting consenus for extension points. Ex tension data needs to start with context. Each extension wil l be one object. Try to allow them only where they'\;re a llowed in XLIFF\n\nreviewed "\;element"\; extension points implemented as has map rather than an array in the la test commit https://github.com/oasis-tcs/xliff-omos-jliff/co mmit/85e7c3e0e8d88539df5b2eb7519d6735f84256e9\n\nDiscuss:\n\ nUse URI type of context or not?\n\nAI Robert [DONE]: To be reviewed\n\nwe have a good structure now\, we just need to add subgroups as per previous minutes\n\nRobert hesitant to add subgroups for lack of semantic difference. Discussed tha t offline with Cahse two weeks ago. Chase also thought that subgroups were unnecessary. \n\nsee discussion of "\;roo t types"\;\n\nhttp://markmail.org/thread/75n3r6sxrbzohgk k\n\nThe distinction between subgroups and subfiles is impor tant for representing all possible root levels as well as en suring interoperability\, the original design was a property indicating the type of root. But the discussion ensued in t he structural proposal that was more automation friendly. In general either the root type property or the strutural diff erence between subfiles and subgoups are needed to preserve the LIOM fragment level when exchanging between technologies . \n\ndF explained the difference between subfiles and subg roups. sublfiles are always top level\, while subgroups can be not only in subfiles but also in other subgroups.\n\nRobe rt agreed to implement and document that\, so that we don 9\;t keep returning to the issue.\n\n \n\nmake context for 2 .0 and 2.1\n\ndF AI to make a PR for forking the 2.0 and 2.1 contexts\n\n \n\n- Continue discussion on extension points\ , look at Robert'\;s commit to introduce extension\n\nhtt ps://github.com/oasis-tcs/xliff-omos-jliff/commit/85e7c3e0e8 d88539df5b2eb7519d6735f84256e9\n\n There are several places where context can be provided: root\, or units\, files\, gro ups. \n\n (Whether @context should be at root or only lower levels).\n\nShould mimic XLIFF behavior as close as possibl e..\n\nWe also agreed that having a dedicated extension cont ainer is more validation friendly than just allowing additio nal properties on the root structure..\n\n-Continue discussi ng pros and cons of the extensionsData approach\n\ncompare w ith XML and consider going back and forth between XML and JS ON.\n\nAI dF and Yves [DONE]: clear usage of XLIFF prefix re gistration mechanism for JLIFF\, request that XLIFF prefixes don'\;t use colon "\;:"\;\n\nraised on XLIFF TC 16th Jan\n\nDONE in principle\, some minor fixes pending\, e .g. FAQ\n\nhttp://markmail.org/thread/qmvyp4yuihx76g6r\n\n \ n\n3- TBX Mapping\n\nTBX-Basic mapping is in order\, almost done on TBXInfo\n\n@James\, would you share the dev page\, o r is it released yet?\n\nC- Other Topics\n\n2- Liaisons\n\nX LIFF 2.1 had to go for COS02 ->\; OS Progress \n\n3- Promo tion\n\nWill have good coverage on GALA Boston in March\, as TAPICC Track 2 will be launched\, building on JLIFF\n\n4- A OB\n\n1- Date of next meeting\n\n13th Feb and 27th Feb look good\n\n \n\n2- Looking for a new secretary. Contact dF\n\n \nGroup: OASIS XLIFF Object Model and Other Serializations ( XLIFF OMOS) TC\nCreator: Dr. David Filip URL:https://www.oasis-open.org/apps/org/workgroup/xliff-omos/event.php?event_id=47010 UID:https://www.oasis-open.org/apps/org/workgroup/xliff-omos/event.php?event_id=47010 RRULE:FREQ=WEEKLY;INTERVAL=4;COUNT=14 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]