XLIFF TC call - Tuesday, 02 October 2012 - Summary

[Yves Savourel <ysavourel@enlaso.com>]

XLIFF TC Meeting
Tuesday, 02 October 2012, 11:00am to 12:00pm EDT

=== 1/ Roll call

Presents: Bryan, Rodolfo, DavidF, Ingo, Yves, Tom, Helena, Fredrik, Jungwoo, Christian, Uwe, Asanka, Joachim, DavidW


=== 2/ Approve Tuesday, 18 September 2012 meeting minutes:

https://lists.oasis-open.org/archives/xliff/201209/msg00032.html
Bryan moves to approve the minutes
Rodolfo seconds
No objections.

Bryan will need to leave at 30mn, Rodolfo will take over.


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

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

--a. Processing requirements for extensions (Yves) https://lists.oasis-open.org/archives/xliff/201209/msg00006.html

--b. Extensions and modules (Rodolfo) https://lists.oasis-open.org/archives/xliff/201209/msg00016.html

--c. (S6) Resource Inheritance (Steven) https://lists.oasis-open.org/archives/xliff/201209/msg00019.html

--d. (S24) Representation of plural entries (Steven) https://lists.oasis-open.org/archives/xliff/201209/msg00020.html

--e. Translations Proposals (Yves) https://lists.oasis-open.org/archives/xliff/201209/msg00036.html

R: similarity is fine.
.. exact match type to drop is fine too (but used a lot)
.. for composite value: don't agree. Origin value could be used for this.
Y: origin is for where it's coming from.
R: broad enough
F: yes, it's whatever you want
R: would be better for parsing.
Y: if consensus is to use origin then it's fine.
R: could drop user-defined value in type
.. any other values in that list?
Rodolfo will make the changes.


--f. FS Attribute (Yves) https://lists.oasis-open.org/archives/xliff/201209/msg00048.html

--g. translate state: https://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/201210/msg00004.html

R: would like to have the second part in a different attribute. Fixed list for the state, and something else for the user-defined
F: separate but related topic: a separate flag for 'locking' a segment.
R: not sure about the difference.
F: locked text is real text but locked for a process reason
R: can't use translate='no' then?
F: no: can't revert the flag
DF: locking where? segment or sub-segment?
F: could use <ignorable> for sub-segment. But inline would be fine too.
.. at least segment, maybe group, but not sure.
DF: agree that lock and translate='no' are different. Would like to see it at all levels
R: would be terrible.
.. we would have conflict between both.
F: not really conflicts.
.. translate=no is more an extractor output
DF: also we may want to lock target
.. for example lock the source on entries without target
.. and what about the override behaviors?
.. lock a group and then unlock some children
R: too complicated
.. working with one flag is simpler
.. two semaphores to check is too much
F: then translate='no/locked/yes' maybe?
R: having two flag is too confusing.
F: locked means it's translatable but currently you should not change it
R: so can unlock at any time?
F: yes. unlocking it is a process problem
DavidW isn't it more like a state rather than a flag?
.. two different concepts.
F: yes, that's why I propose two attributes
R: could change the attribute name
F: don't see translate in unit
R: at the segment level
DF: think those are two different things
.. should be able to lock at any level
.. translate state should exists only on translation
.. translate attribute is different (same semantics as ITS)
R: ITS irrelevant
DF: but same semantics
F: translate=yes/no is a problem. It's the only way to lock things
.. overloaded usage makes thing difficult
Yves: not sensing consensus
Christian: Coming back to Yves' proposal for encoding status information: I understand that 
it would be great to combine a fixed set of values, with something user-defined. 
To me, this related to the question of how to implement inheritance. One standard 
that has implement this is DITA (see for example "- topic/topic task/task ").
Helena: can someone send out an example when a lock will take place?
R: should we add translate at unit level?
.. will do.


--- 2. XLIFF 2.0 Technical issues (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#TechnicalIssuesforXLIFF2.0 )

--- 3. Conformance criteria

R: I updated the specification on this.
Adapted the 1.2 errata for 2.0
It's in the PDF, its own section.
F: issue with how we can define the preservation of extended data when splitting or merging segments.
.. what happened to the metadata?
R: up to the application
.. behavior is defined in extension definition
F: so we should add this in conformance section too
R: so will add wording about exception for removal

Christian: What happened to the input I provided on conformance (see https://lists.oasis-open.org/archives/xliff/201010/msg00013.html
R: could you make a concrete proposal for a change.
Christian: The proposal is in the mail
.. maybe not everyone has seen this proposal.
.. two inputs
R: the proposal talks about conforming applications. Don't think it's possible
CL: yes, pertains to both applications and markup (two sections)
F: talking about conformance transformation may be the solution (it's not about the application)
R: comparison between file before and after is possible, but we can't say anything about the tool
CL: we should talk about processing conformance 
R: we have processing expectations
CL: sure, and then conformance clause should say so
R: it is saying this in the third paragraph
CL: asking for feedback on the two proposals
R: my proposal was discussed already.
F: issue with 1.2 is that there are no processing conformance requirements
.. stricter processing conformance is better
R: extensibility prevent that
F: points where extensions are allow should define the expectations too
R: we do have that at the end of the Extensibility section
F: yes.
.. will try to write an additional section for the conformance clause
CL: what is the procedure? Will we have a vote on the conformance section?
R: when spec is ready, we vote on each piece
.. not in one piece
.. part by part
CL: suggest we vote on how to approve the specification
R: We will we have to approve as a whole at some point. But before we need to discuss on each parts
.. we can vote on each part
.. ballot can be proposed at any time


--- 4. Charter: Need to bring up to date to reflect XLIFF 2.0

David's proposal https://lists.oasis-open.org/archives/xliff/201209/msg00001.html
Here’s the current charter
http://www.oasis-open.org/committees/xliff/charter.php

R: any feedback?
DF: nothing on the mailing list


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

--- 2. XLIFF Promotion and Liaison SC Charter (David)
DF: XLIFF symposium is in two weeks.
CL: any plans for summaries
DF: will publish proceedings
CL no plan to produce a summary report?
DF: good idea
CL: would have liked it for the second symposium
DF: agree
Y: what about the face-to-face?
DF: people coming need to ask me.
Will be in Redmond
R: will we have a GoToMeeting?
DF: afternoon we should have session open to remote
.. probably not make sense to have the full session open to remote (not practical)
.. I think that's the plan.
.. then we'll have an info session for public

DF: face-to-face attendees please report by Oct-5


R: Lucìa has her PhD and no longer member of the LRC.
She's not in TC for the time being.
Will try to re-join later


=== 5/ Current XLIFF business

=== 6/ New Business

-adjourned