[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Modified: 4th Tuesday - Regular XLIFF OMOS TC telecenference
|
Event Title: 4th Tuesday - Regular XLIFF OMOS TC telecenference Date: Tuesday, 26 September 2017, 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 7 Voters total
2- Minutes from the last quorum meeting 2017-07-23 https://www.oasis-open.org/apps/org/workgroup/xliff-omos/email/archives/201707/msg00011.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? In jliff the root object has no name and carries the global information such as jliff version. AI: To create JLIFF examples with each possible root. - 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? Ján Husarčík will submit new samples this week
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) TBX had good meeting in Vienna, strong consensus allowing for modernization of industry relevant profiles of TBX. 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. XLIFF TC - XLIFF Version 2.1 will progress to cos01 3- Promotion 8th XLIFF Symposium CFP has been extended The main conference is Nov 1-Nov 3, FEISGILTT will be held on Oct 31-Nov 1, 2017. Save the dates. https://locworld.com/events/feisgiltt2017/
4- AOB 1- Date of next meeting https://www.oasis-open.org/apps/org/workgroup/xliff-omos/email/archives/201709/msg00000.html 26th Sep, 10th Oct, 14th Nov, 28th Nov, 12th Dec. Which brings us to the end of 2017.
So that means I am also looking into a volunteer to chair 24th Oct, where I will be at tcworld Stuttgart and again unable to chair.
2- Both OMOS Secretaries had resigned at this point, so I am looking into volunteers for the secretary role. Also we are looking into a backup maintainer for the OM Github repo Minutes A. Admin 1- Roll call David, Chase, Phil, Yves, Robert, James 6 out 7 Voters total B. Material 1- XLIFF OM (https://github.com/oasis-tcs/xliff-omos-om)
2- JLIFF (https://github.com/oasis-tcs/xliff-omos-jliff) dF: Type is indidcated on line 4. Robert: Some things are not showing, such as “jliff-version” dF: Can you please update the examples? Robert: Yes
Phil: The different root implement a common interface which is minimal. The other mechanism was to have property names which was in the root of the file. Chase: Is this different than what is in the spec?
dF: I think we can show this at the conference next month as the minimum viable product. I also think it’s time to make design decisions.
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 unit 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 "$" dF: What is our approach to namespaces? Did anyone have a chance to experiment with namespaces in JLIFF? Phil,Chase: Not yet. dF: I think that MDA is the most suitable because it has Key-Value pair structure. dF: Do we want to make a provisional decision that we go with the JSON LD mechanism for shortening names? Robert: I second that. JSON-LD will be a good candidate for allowing us to integrate namespaces. I think we need to make a plan, next meeting, can we discuss JSON-LD in more detail? dF: I think for the next meeting we need an example of using JSON-LD. Also, I don’t remember consensus with a specific separator. We were undecided between “:” and “_”. “:” maybe looks too XML-ish. dF: Both “_” and “:” appear in IRIs. We can make sure that the appearance of them is separated since we have control over the registered prefixes, so we can make sure that the first "_" or ":" is the separator. Chase: I’m partial to the “:”. “:” seems like a markup language component while “_” feels more like programming syntax. dF: “_” may look forced, like we are deliberately avoiding looking like XML. Yves: I actually did a lot with namespaces, using “_” in the last experiment, but “:” should be fine. Robert: both are aloowed in JSON names, “:” is the separator in JSON-LD names. I am in favor of going in that direction.
dF: - 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. dF: Yves, in your experiments, were you using explicit context, or were you assuming context in a registry or something? Yves: I was mostly working with the module, assuming that the prefix was known [i.e. implicit context]. dF: So you were not using explicit context? Yves: Not at this point, no. dF: it seems an advantage to not using explicit is that file size gets large when it is used. dF: Do we want to make a decision on this? Chase: For some use cases the fully qualified JSON names have potentially a lot of overhead. I am not certain whether we should support both or only one. It seems like having the short-form is good sometimes. dF: There is an article about XML vs. JSON that the implementers should read (https://www.linkedin.com/pulse/horses-courses-perspective-xml-vs-json-discussion-ken-holman/) dF: He makes the point about XML being globally unambiguous. He has some good thoughts about using the fully qualified context and shorthand. XML is much more audit friendly than JSON. It seems it depends on use cases, as Chase mentioned. dF: I don’t feel we are able to make a decision at this point. dF: Any other JLIFF questions we need to pursue? [no response]
- Using XLIFF 2 test suite to test JLIFF expressivity wait for XLIFF 2.1 test suite Soroush? status? There will be new extraction /merge example by Moravia, should appear either on XLIFF SVN or TAPICC GitHub..
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) dF: We are waiting for the ISO standard to be technically stable. James, the new TBX should be modular, unfortunately unclear about namespaces. Namespaces will probably prevail but not sure if a namespace will be for the extension or for the whole dialect-vocabulary..
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. WG3 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. Chase: TAPICC has a very aggressive goal to produce by the end of the year. What does this mean for us? dF: All current Working Groups are in Track 1, so they are not dependent on our progress, they use just the XLIFF original XML. Next year we can try to launch the second and third tracks. Probablz at FALA Boston 2018. This could be a motivation for us to have something prepared (testable, workable, presentable) for this. It should be feature-complete for those features which we choose (not necessarily everything), by next March. How is that? Robert? (not sure): Possible.. dF: Possible is good!
dF: Ballot on cs01 will start soon.. We have collectied enough statements of use to progress with the standard. So XLIFF 2.1 should be in candidate OASIS status in two weeks or so...
3- Promotion FEISGILTT / XLIFF / JLIFF Symposium schedule published https://locworld.com/wp-content/uploads/2017/10/FEISGILTT2017Program.pdf Registration open https://locworld.com/events/feisgiltt2017/
4- AOB 1- Date of next meeting 2- Looking for a new secretary. Contact dF dF: We will probably send out a Doodle to decide on a date. We also still need a secretary (or even a co-chair) so someone can host meetings, maintain the roster, and such. We mostly need a stable backup for chairing. Please contact me if you are interested. dF: We are skipping Oct. 24th. Do the other dates (10 Oct, 14th Nov, 28th Nov, 12th Dec) sound good? [yes] dF: meeting adjourned 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 |
Attachment:
ical_41676.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:20171010T124757Z DTSTART;VALUE=DATE-TIME;TZID=Europe/Lisbon:20170926T170000 DTEND;VALUE=DATE-TIME;TZID=Europe/Lisbon:20170926T180000 SEQUENCE:12 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:20171010T124757Z 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\n7 Voters total\n\n \n\n2- Minutes from the last q uorum meeting 2017-07-23\n\nhttps://www.oasis-open.org/apps /org/workgroup/xliff-omos/email/archives/201707/msg00011.htm l\n\n \n\nB. Material\n\n1- XLIFF OM\n\n(https://github.com/ oasis-tcs/xliff-omos-om)\n\ncheck the wiki mapping\n\nhttps: //github.com/oasis-tcs/xliff-omos-om/wiki\n\nJLIFF unlike XL IFF has the capability to represent fragments at different l ogical levels ->\; need for a wrapper object in JLIFF at t he top level\n\n- what has to be on the logical root level?\ n\nlist: srcLang / trgLang ...srcDir / trgDir .. whitespace handling (how?) more?\n\n \n\n2- JLIFF\n\n(https://github.co m/oasis-tcs/xliff-omos-jliff)\n\nFollowing the OM discussion and the JLIFF capability to represent fragments from differ ent logical levels\n\nConsensus: JLIFF objects and arrays wi ll be always wrapped with a top level object (thus necessari ly nameless) indicating jliff version and other global prope rties of the fragment. \n\nWhat can be inside / what is vali d JLIFF content? :\n\nfiles --- the top level object corre sponds to XLIFF\n\ngroups | units --- the top level object c orresponds to file\n\nsubunits --- the top level object corr esponds to file\n\nIssue: if content is units what'\;s th e corresponding XLIFF level? Could be group and could be fil e. This has potential to break roundtrip..\n\n- what has to be on the wrapper level? \n\nlist: JLIFF version srcLang / t rgLang ...srcDir / trgDir more?\n\nIn jliff the root object has no name and carries the global information such as jliff version.\n\nAI:\n\nTo create JLIFF examples with each possi ble root.\n\n- Continue discussion on qualified names\n\nPos sible prefixes? \n\nunderscore "\;_"\; \n\ncolon &qu ot\;:"\;\n\ndolar sign "\;$"\;\n\n \n\n- Look at JSON-LD? Use of context\, no namespaces\, but a way to shor ten IRIs\n\nNeed to look into a prefix registration mechanis m preferably indepnedent on the XLLIFF TC SVN? \n\nThe group consenus seems tending to identification of context for mod ules and registered extensions.\n\nWe can control via the re gistration mechanism that the first _ or : or $ or whatver t he consenus is the separator of the qualifier.\n\nNote that this leads to top level "\;pseudoobject"\; defining that context that JSON theorists don'\;t seem to like. Bu t we need that the capture the logical top level anyways.\n\ n \n\n \n\n- Using XLIFF 2 test suite to test JLIFF expressi vity\n\nwait for XLIFF 2.1 test suite\n\nSoroush? status?\n\ nJá\;n Husarč\;í\;k will submit new samples this week\n\n \n\n3- TBX Mapping\n\nReport from editorial 1- 2-1 meeting [skipping until TC 37 meetings in Vienna late Ju ne]\n\ncurrent editor'\;s draft: https://tools.oasis-open .org/version-control/browse/wsvn/xliff-omos/trunk/XLIFF-TBX/ xliff-tbx-v1.0.pdf\n\nVienna aftermath report (dF/James)\n\n TBX had good meeting in Vienna\, strong consensus allowing f or modernization of industry relevant profiles of TBX. \n\nC - Otherr Topics\n\n2- Liaisons\n\nWhere to place work on ext raction reference guides? Seems industry want that..\n\nProp osed that as TAPICC track inside Strand 1 Supply Chain Autom ation\n\nGALA TAPICC https://www.gala-global.org/tapicc-tran slation-api-class-and-cases-initiative\n\nhttps://www.gala-g lobal.org/publications/translation-api-class-and-cases-proje ct-statement-tapicc does not require GALA Membership. OMOS o bject model is linked to 2nd and 3rd tracks of TAPICC.\n\nXL IFF TC - XLIFF Version 2.1 will progress to cos01\n\n3- Prom otion\n\n8th XLIFF Symposium CFP has been extended\n\nThe ma in conference is Nov 1-Nov 3\, FEISGILTT will be held on Oct 31-Nov 1\, 2017. Save the dates.\n\nhttps://locworld.com/ev ents/feisgiltt2017/\n\n \n\n4- AOB\n\n1- Date of next meetin g\n\nhttps://www.oasis-open.org/apps/org/workgroup/xliff-omo s/email/archives/201709/msg00000.html\n\n26th Sep\, 10th Oct \, 14th Nov\, 28th Nov\, 12th Dec. Which brings us to the en d of 2017.\n\n \n\nSo that means I am also looking into a vo lunteer to chair 24th Oct\, where I will be at tcworld Stutt gart and again unable to chair.\n\n \n\n2- \n\nBoth OMOS Sec retaries had resigned at this point\, so I am looking into v olunteers for the secretary role.\n\nAlso we are looking int o a backup maintainer for the OM Github repo\nGroup: OASIS X LIFF Object Model and Other Serializations (XLIFF OMOS) TC\n Creator: Dr. David Filip URL:https://www.oasis-open.org/apps/org/workgroup/xliff-omos/event.php?event_id=41676 UID:https://www.oasis-open.org/apps/org/workgroup/xliff-omos/event.php?event_id=41676 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]