XLIFF TC Call Date: Tuesday, 19 April 2011 Time: 11:00am - 12:00pm ET === 1/ Roll call Presents: Rodolfo, David-F, Yves, Bryan, Christian, David-W, Andrew, Peter, Lucìa === 2/ Approve Tuesday, 15 March 2011 meeting minutes: Accept, reject, or amend. (
http://lists.oasis-open.org/archives/xliff/201103/msg00005.html ) Bryan moves to approve. Rodolfo seconds. No objection. Note: Though not an official meeting on the books, please review the notes from last meeting (
http://lists.oasis-open.org/archives/xliff/201104/msg00004.html ) === 3/ XLIFF 2.0 (
http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking ) - XLIFF Core Thread (
http://lists.oasis-open.org/archives/xliff/201104/msg00005.html ) - New updated schema posted by Rodolfo today:
http://lists.oasis-open.org/archives/xliff/201104/msg00046.html Bryan: Active mailing list between last meeting and today -> good. Questions from Rodolfo about the latest schema: --- Question: Multiple files in xliff doc? - Most: +1 - Christian: can't say yes or no. Need more explanation and time, in writing if possible. - Rodolfo: This is just a starting point, we may change later, but we can continue drafting with this. We can change everything. This is just to keep moving forward. Will document the schema when we have a broad agreement. Peter: This is not a binding vote, just to know if this is the direction most agree with. But agree that we need to examine things in details Rodolfo: But need quick feedback to construct a starting schema Bryan: Understanding is that this is feedback on Rodolfo's current work, nothing more. Rodolfo: yes. Bryan: We do need input from wider range of people, but this track is fine for now. --- Question: several elements or a one element for containing collection of children? (e.g. matches element as container or directly several match elements) David-F: Containers sounds useful Rodolfo: Containers may be useful for reading David-F: Maybe naming convention if it's a container. Bryan: Generic names are useful: help to focus on new functionality. We may change this latter. --- Question: what happened when joining two consecutive segments? Should the ignorable elements be converted to inline codes or content? Peter: How Trados Studio does this? Andrew: In this case we concatenate, so the ignorable becomes part of the segment. Real ignorables are in different trans-units (with translate='no') Rodolfo: will depend on the inline markup. For now I'll assume ignorable -> inline Reverse too: splitting segment: inline could be moved out of the segment and become ignorable. David-F: puzzle about the sense of "ignorable" Rodolfo: ignorable for the translator David-F: maybe this belongs to different module? May be critical for reconstruction Rodolfo: no removal, just protecting the data from translators. Required for recreating document. Bryan: to me it's like an XML PI Andrew: for me the space would go as ignorable between several sentences in a paragraph Rodolfo: see XSD: whitespaces or formatting codes, etc. Other option: Could have segment with inline and the segment marked as translate=no David-F: seems clearer to me. Sounds more like skeleton-type data Rodolfo: we should be able to split/merge anything inside a unit. Yves: +1 David-F: Agree with general methodology. But here is a space for a hook. Splitting/merging should be done based on rules Rodolfo: human segmentation here, translators should be able to change segments David-F: should mark this for later discussion Previous 1.2 group was used (overloaded for segmentation) Rodolfo: will update the schema --- Question: should we keep note there for now? For storing a comment David-F: in core or other module? Think whole module needed for "annotation" (includes note) Bryan: let's call it "simpleNote" maybe Rodolfo: ok Bryan: Thanks for the work Rodolfo. David-W: what is the audience? Still a question for me, because it may change the core per user/usage Bryan: agree, we don't know yet what is core or not Way to look at this would be looking at 1.2 features and do a check list. David-F: from industry feedback it seem there is a need for a very basic core. Micah's matrix seems to show that too. Citation: XLIFF is basically an "open standard bitext" (from Dag Schmidtke (Microsoft)), that sounds like a good core. Bryan: think we have not begun yet to define the core. Modules are no less important But very simple core seem a good goal Rodolfo: later we could publish different schema with different module And a unified schema as well. === 4/ Current XLIFF business === 1. Peter's request that our TC, along with former OSCAR members discuss OASIS/XIFF taking over TMX/SRX (
http://lists.oasis-open.org/archives/xliff/201103/msg00015.html ) Peter: More confused than ever. Maybe need to let things settle a bit. Reluctant about a "large" meeting. No sure how to move forward at this point. Think SRX is crucial in addition to XLIFF. No sure for the ex-LISA standards. Heard TBX and SRX should be done by some, while TMX should be handled by XLIFF. Anyone has any ideas? Bryan: SRX as an XLIFF module? Peter: SRX not as a module, just that it's useful. TMX has less momentum. Several think XLIFF should be used a TM exchange. David-F: agree that SRX is important, but don't think XLIFF TC should work on this. It's more like a Unicode case. Helena has now a localization TC in Unicode: So maybe the segmentation aspects would be taken care by Unicode Rodolfo: if XLIFF good exchange format between tools, then we could provide a way to include those info in XLIFF (e.g. embed SRX in XLIFF, TBX for term bases, etc.) And let other define what those formats are. Peter: feeling is that we can wait until things are settled. David-F: as XLIFF TC we should say that TM-exchange would be taken by TC. Bryan: maybe we need more formal definition statements ACTION ITEM: Peter and david-F to come up with proposal === 2. ISO/OASIS XLIFF - XLIFF as an ISO standard (Peter) (
http://lists.oasis-open.org/archives/xliff/201010/msg00004.html ) MLIF being mentioned (
http://www.tc37sc4.org/new_doc/ISO_TC37-4_N266_WD_Multilingual_resource_management.pdf (outdated maybe)) In ISO TC-37, uses XLIFF/TMX/etc. would become part of this umbrella format. Seems mostly academic project Will answer Kara: no interest in MLIF David-F: trying to form a consortium to help in implementation of those standards Working with MLIF would reduce our chance, MLIF is seen as a failure. Peter: heard some strong views that we should not work within the MLIF framework David-F: fine with reply to Kara === 3. XLIFF Symposium Debrief: "Voice of our customer" (Christian) - Christian is in contact with Multilingual and has written to Robin Cover Tabled for next time. === 4. 2nd Annual XLIFF Symposium in Poland progress (Peter) Nothing special yet. Call for paper soon. People liked last year's symposium. === 5. Gathering common extension points from existing XLIFF Tools as a guide for 2.0 features (Bryan, Thomas) (
http://lists.oasis-open.org/archives/xliff/201101/msg00007.html ) - Lucia has taken over Micah's matrix Bryan: matrix started. Lucìa: But agree with Rodolfo's point, so backed it up and took it off-line Bryan: seem this is a useful tool, maybe we can improve it and then decide to make it public Lucìa: maybe we can change the methodology. Public call for the info, or open web page where to put the info and they are responsible for the content. Rodolfo: issue: OASIS is charging for this type of pages. David-F: want to see how much it is. Bryan: though someone (Scott maybe) gave that info, no? David-F: TAUS wants to be the "watch dog" (dashboard). Trying to push that idea toward the users. Peter: See
http://lists.oasis-open.org/archives/xliff/201104/msg00002.html for price - Extension Schemas added for XTM and MemoQ (thanks to Andrzej, Peter, and Rodolfo) Some added. === 6. XLIFF Spec in XLIFF (
http://lists.oasis-open.org/archives/xliff/201102/msg00011.html ) - Lucia provided the paper work to get this started. Bryan will ensures the papers this week. Got the agreement. Process will start soon. We could publish the XLIFF of XLIFF David-F: would be good answer to some. Rodolfo: strange that some people would think it's not possible. Yves +1 Bryan: looking at it from start->finish process viewpoint. Using DocBook goes further back, its' a more compelling story. === Various 7. TAUS role extended to Interoperability Watchdog (Bryan) (
http://lists.oasis-open.org/archives/xliff/201103/msg00009.html ) 8. GALA Lisbon roundtable on changing landscape of localization industry standards (Yves, Lucia) (
http://lists.oasis-open.org/archives/xliff/201103/msg00012.html ) 9. Variants - Wording in Spec (Christian) (
http://lists.oasis-open.org/archives/xliff/201103/msg00021.html ) No comment === 10. Sub Committee Reports - Inline text (Yves) Worked on the permission for inline codes (can delete/replicate/etc.) Working also on output examples. === 6/ New Business David-F: we need to stop on time, or to plane more time. Bryan: Got the message. Maybe 60mn not enough, maybe 90mn would be ok. Hopefully admin part will get smaller. Send opinion if you have any. -end