[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XLIFF TC - Dec-16-2014 - Summary
XLIFF TC Meeting - Summary Date: Tuesday, 16 December 2014, 11:00am to 12:00pm EST === I Administration (0:00 - 0:10) --- A. Roll call DF: we have quorum. --- B. Approve meeting minutes, 2 December 2014 https://lists.oasis-open.org/archives/xliff/201412/msg00040.html BS: moves to accept the minutes TC and DF: second === II XLIFF 2.1 (0:10 - 0:45) --- A. Versions and Modules - Yves https://lists.oasis-open.org/archives/xliff/201410/msg00037.html * Concluded by Yves here: https://lists.oasis-open.org/archives/xliff/201412/msg00024.html DF: We have feed back for the MIME type registration. .. And we can merge this with 2.1 .. if anyone object, do it now. Nobody objects. --- B. Provenance and Change Track Module (Yves) https://lists.oasis-open.org/archives/xliff/201410/msg00045.html --- C. ITS: Preserve space and Language Information https://lists.oasis-open.org/archives/xliff/201410/msg00054.html --- D. @disabled in Validation Module. Fix example. Add constraint? (Bryan) https://lists.oasis-open.org/archives/xliff/201411/msg00000.html BS: I redraw this issue --- E. TBX ? XLIFF Mapping - this will be a note (DavidF) F: this one is decided: it's a Note .. just need to do the work. --- F. ITS IG Call 2014-11-10 - Yves https://lists.oasis-open.org/archives/xliff/201411/msg00037.html --- G. Do we have to have the schemas embedded in the specification? - Yves https://lists.oasis-open.org/archives/xliff/201411/msg00040.html - ruling from OASIS: ?The schema need not be incorporated into the narrative spec document. If it is, the practice is to put it in an appendix and include some notice or reference to the external copy. If you put it in the spec, you must include it as an external file as well. Also, in case of discrepancy, the external copy is authoritative.? DF: Phil and Chase sent feedback: they are OK with .. removing the schema in the specification. .. Do we need a call for dissent? .. If anyone do not want to remove the listings? Nobody disagree. DF will remove the listings. --- H. Terminology data category - Yves https://lists.oasis-open.org/archives/xliff/201411/msg00041.html --- I. ITS IG ACTION-56: Do write up of processing its+xliff files - Yves https://lists.oasis-open.org/archives/xliff/201411/msg00047.html --- J. Provenance Data Category - Yves https://lists.oasis-open.org/archives/xliff/201411/msg00052.html --- K. ITS module section(s) in the specification (Yves) https://lists.oasis-open.org/archives/xliff/201411/msg00083.html --- L. *Template/Model for TBX Mapping with XLIFF v2.0 and Higher Version 1.0 (DavidF) https://lists.oasis-open.org/archives/xliff/201411/msg00091.html DF: we should keep this one alive. .. as a placeholder. .. still not resolved. Front matter is different. --- M. A quick note on "Notes" (DavidF) https://lists.oasis-open.org/archives/xliff/201411/msg00092.html --- N. ITS Module URI (Yves) https://lists.oasis-open.org/archives/xliff/201411/msg00097.html YS: this was decided by email. --- O. *XLIFF Promotion and Liasion SC - mandate extension (Lucía) Ballot to approve https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=2719 https://lists.oasis-open.org/archives/xliff/201412/msg00009.html BS: this is admin related. DF: and it's resolved too. .. the SC is extended --- P. Comment on B.2.1.2 Inline Elements section (Yves) https://lists.oasis-open.org/archives/xliff/201412/msg00045.html YS: think tips provided are not good. Better solution is to let extractor normalize the content where needed, and set unit to preserve. F: agree. It's simpler solution DF: think the section provides various solution like using data to store the spaces. FE: proposed solution is simpler .. it simply explains how to achieve the same result with what we have. JS: need to understand better the solution .. question: could the solution cause issue with segmentation? FE: possibly if extraction is done at too small level .. but a reasonable extractor should be OK. DF: current description is not normative FE: we may not even need a special attribute for inline preserve space. DF: we never prescribes what extractor do .. it is still valid to have the attribute for full-fledge behavior FE: for our implementation we preserve space always DF: that's implementation specific .. Yves' solution is a fourth one YS: agree, but think the 3 first are not very good FE: it should be ok to make an extractor knowing only about the format, not the linguistic DF: the 4 strategies are valid I think FE: but that would not be following 2.x way of trying to offer a single way to do one thing DF: but this is not normative .. so it's OK to have several solutions JS: Looked at the different solutions .. I think the fourth one is the best DF: Yves can you re-word it? YS: yes I can FE: so do we still need the special attribute? DF: maybe not as a separate module, but yes as an attribute .. this way all extractor can provide support YS: not sure, as the attribute would be a first choice FE: as long as the method 4 is done, then adding the attribute is just extra info. .. this is the only way to have the extraction safe .. only value I see with the attribute is to carry the info into XLIFF DF: usually preserve space inline is set when the paragraph is not set with preserve space .. so the idea would be that preserve space could be achieved with just the core metadata BS: are we closing in on a solution? DF: discussion probably need to continue online .. I can see the relevance of not having the attribute FE: we just need to decide if there is a value to carry the info BS: Ok, so the thread is to be continued on the mailing list --- Other topics: FE: Behavior of ignorable is not completely define for segmentation. .. What happened with merging segments with target with an ignorable without target .. using the source seems ok DF: yes FE: will need to post an email to be sure this is clear for all DF: not sure why allowed characters is not allowed structural YS: just following the pattern DF: Tom, could you start working on XSD for the ITS module TC: yes, I'll try this week. DF: Soroush is developing Schematron for validation .. it seems 2.0 doesn't prevent use to have XLIFF without a segment .. we can have an empty group .. this is not forbidden FE: Don't see it as an issue .. for example it ensure that you can get an output file for each input file BS: agree with that. .. this goes back to having multiple <file> is a document. .. think it's OK FE: it is a bit inconsistent to not all just an empty file though === III Sub Committee Report (0:45 - 0:55) BS: quick report David? DF: We are working on the call for paper for the XLIFF symposium .. anyone with idea for general topics, please send them .. the call for paper should come out this week .. we'll need to push the info on social network .. we will have CNGL funding for the symposium DF: also, I've formatted the ISO request to Chet and Jaimie .. we didn't hear back so far. === IV Current and New Business (0:55 - ) BS: any one with new business? None BS: make sure to fill the Doodle poll for Jan-6 Meeting is adjourned. -end
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]