RE: [xliff] XLIFF TC - Dec-16-2014 - Summary

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Thanks Yves.

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Tuesday, December 16, 2014 9:08 AM
To: XLIFF Main List
Subject: [xliff] 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



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php