XLIFF TC Conference Call - Summary - Dec-18

[Yves Savourel <ysavourel@enlaso.com>]

XLIFF TC Conference Call - Summary
Date: Tuesday, 18 December 2012, 11:00am to 12:00pm EST

 
=== 1/ Roll call

Presents: Shirley, David-F, Asanka, Bryan, Uwe, Victor, Peter, Ryan, Helena, Jungwoo, Fredrik, Michael-O, Joachim, Kevin, Tom



=== 2/ Administration

--- 1. Approve Tuesday, 04 December 2012 meeting minutes:

https://lists.oasis-open.org/archives/xliff/201212/msg00023.html
Includes David's clarification on the "unpronounced ballot" - abstains vs. yes'

Bryan moves to accept the minutes
Fredrik seconds
No objections.

B: most discussion was about binary unit and a few other proposals.
.. there are no remaining proposals in section 2
.. clear but controversial path ahead, that's ok.
.. tried to summarized the discussions in email this morning (for binary module)



=== 3/ XLIFF 2.0 (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking )

--- 1. Features proposed/discussed on the mailing list

- a. Binary Data Module (Ryan) https://lists.oasis-open.org/archives/xliff/201212/msg00063.html
Note: I add this agenda item not as approve/disapprove - it has already passed. I add it in hopes that we can summarize all the voices that have weighed in, and work toward a better understanding. I will try to parse the mailing list and provide a working summary of those who have weighed in

B: We can shade some light in this module.
K: quick reasons why we need the binary module:
.. was in 1.2 not in 2.0
.. looked like a major block for the SharePoint team
.. tried to maintain some parity with 1.2
.. try to better organize the feature, not to change it completely
.. from our viewpoint it's a simple module
.. Not sure about some of the feedback
B: bin-unit was in 1.2
.. looked for issue, didn't see any controversy
.. possible slight difference in the way it's intended to be used
.. but rarely used, that's one of the reason why we didn't put it in the 2.0 core
.. (no champion for it)
H: wonder why we can't use file+skelton for this function
B: +1
D: I think there are two different functionalities
.. one is to support the SharePoint use case
.. second was the elaboration Ryan proposed
.. those are different use cases
Joachim: agree
.. don't see why text content be in XLIFF
.. having binary files in XLIFF will be difficult to work with
.. translatable data should be outside the binary data
.. that's our main issue
.. this said: I do understand the use case of SharePoint
.. and we need a solution for it
.. to me this solution is possibly in the container
B: saw the use case of having the binary data needed because it needs to be resized
F: that is the second use case
.. different from the case where whole documents are put in binary units
D: binary data should be allowed at the file level only
.. not sure how compatible with skeleton
.. SharePoint is not the only use case, other CMS as well have this use case
.. the binary data doesn't clash with the extracted text
.. it's like a cascading processing
.. skeleton is also a way to deal with binary data
.. having this in a module is better than in 1.2
.. those are not extracted data
Joachim: our clients would still have to read the module
D: I like the proposal for registering MIME type
.. that would improve interoperability
Joachim: that applies to the other use case
D: I think it applies to both
Joachim: handling the binary data will be difficult
.. the issue is the user
D: the important part is that the module has metadata
.. so data can be identified
.. but this may cause problem later on with additional module
B: Is this getting more complex that it needs to?
.. can we have binary unit with all text in trans unit?
F: different use case
.. first case: full file: apply process to the bin data and do the translation
.. then create the target
.. simple case, but not understand why doing this
.. second use case: some binary data must be modified but are not stored in XLIFF metadata
R: why this second use case is 'more traditional'?
.. this is very common for us
.. using binary data along with the unit is valid
J: we understand that
.. that the original use case
R: so the issue is that the two use cases are mixed?
J: yes
.. also having more interoperable metadata would be better
.. so mechanism is needed to store such info in an interoperable way
.. but it would be hard to maintain
.. so result may be like as vague as 1.2
R: think we are not opposed to split the two use cases
.. having another module for whole file would be ok
.. but need to make sure we don't have regression from 1.2
D: why would MIME type would failed Joachim?
J: hard to maintain (not many resources)
D: most of the burden should be on the one registering it
.. would MS be willing to register such types?
R: think it would be fine, because they need to be public in some form
J: in that case second use case would be fine.
Y: not sure why TC would need to maintain some registry?
D: because XLIFF specific process 
R: we use MIME type because was used in 1.2
.. but maybe if we split feature, it may be better to have our own registry
D: yes, then we could have PE
J: yes, but those could be also real MIME type too (JPG)
B: so for resource use case we would be the registry
R: and we could also have PR specifying that if the resource is MIME type we should use that
F: or use always MIME type and have our list of MIME extensions (x-) and the TC would keep that list
R: that would be consistent
B: time is ticking.
D: We should have at least 10mn for the inline part. rest can wait.
R: for the resource case I think we may need to fine tune the attributes, can do that online
.. and the file case can be tabled later.
B: Post 2.0?
R: no, post this meeting
.. current proposal is for resource use case, and need separate discussion for the file case

ACTION ITEM: Ryan to start the different thread for the two use cases and solutions


=== 4/ Sub Committee Reports
--- 1. Inline text (Yves)

Y: proposal is now in the TC hands.
.. all is the the specification and schema
D: think there are some issues:
.. one is the extensibility in <mrk> and <sm>
.. the other re-segmentation behavior (locked segmentation)
F: another is 'what to do when there is existing target'
.. but it's a different discussion
.. for me it depends on if XLIFF is an exchange format or also a processing format
B: so now the TC owns the proposal
.. any work on it should be done there.
.. thanks to the SC for the work.


--- 2. XLIFF Promotion and Liaison SC Charter (David)

D: there is a P&L SC meeting after this call.
B: anyone can attend to get the debrief
.. and later to
D: New call for program committee. Next XLIFF symposium would be in London in June (around LocWord)


=== 5/ Current XLIFF business
=== 6/ New Business

B: any new business
D: three new voting members: Michael-O, Ryan and Kevin are voting members (16 voting members now)
B: Thanks for the work in 2012
.. looking forward to 2013.
.. Happy Holidays!

-end