XLIFF teleconference - may-15-2012 - Summary

[Yves Savourel <ysavourel@enlaso.com>]

XLIFF teleconference - may-15-2012 - Summary


=== 1/ Roll call

Present: DavidW, Lucia, Rodolfo, Shirley, Helena, Yves, Victor, Fredrik, Alan, Steven, Uwe, Tom, Arle, Christian, Kevin, Jung, Klemens
Regrets: Bryan, Asanka, DavidF


=== 2/ Approve Tuesday, 01 May 2012 meeting minutes:
http://lists.oasis-open.org/archives/xliff/201205/msg00000.html

Tom move to approve the minutes.
Arle, Fredrik second.
No objections.


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

--- 1. Features proposed and seconded between meetings via mailing list, and features mentioned

a. Proposed and seconded: (B25) Preserve metadata without using extensibility" (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-PreserveXMLattributeormetadatawithoutextensibility.A.28B25.29Preservemetadatawithoutusingextensibility   )
- Extensibility sub thread (http://lists.oasis-open.org/archives/xliff/201203/msg00077.html  )
- Implementing extensions sub thread (http://lists.oasis-open.org/archives/xliff/201203/msg00078.html   )

Ballot about "should we have extensibility": ballot passed.
Fredrik: good to see so many people voted.

Second part: 3/4 options.

a) using namespace only
b) using metaHolder-like XLIFF module
c) using both
b) using metaHolder-like XLIFF module (possibly using namespaces for values in a metaHolder-type)

Rodolfo: Should we have an electronic ballot too? (rather than decide now)
Fredrik: yes
Victor: agree

Should we wait until next Friday to issue the ballot?

Christian: I would first like to have a discussion of the options. This should include examples.
Kevin: agree with this - would like to see some more discussion time 
Steven: agree as well.

Rodolfo: sure. We can commenting start now 
Fredrik: Regardless which solution we pick, we'll have to 'design' the feature (e.g. where it's allowed, etc.) afterward.


b. Overloaded http://lists.oasis-open.org/archives/xliff/201202/msg00009.html
c. String length constraint (should be added to wiki) http://lists.oasis-open.org/archives/xliff/201202/msg00059.html

R: some features have been in the list for some time: String length constraint
Fredrik: yes I'm interested
Need more feedback before to propose it as feature.
Rodolfo: we need to move forward on all those topics.
Fredrik: last time we discussed it there were concerns about complexity.
A better solution is needed
We can drop it from agenda until it's ready, or drop it completely.
Rodolfo: think it's useful, we just need a starting point.
Fredrik: will work on proposal


d. Attributes for translation candidates http://lists.oasis-open.org/archives/xliff/201202/msg00082.html

Yves: that one is mine. Will try to make it move forward.


e. Unified XML schema for XLIFF 2.0 http://lists.oasis-open.org/archives/xliff/201202/msg00099.html

Rodolfo: propose to drop this one.
Not sure if we need a unified schema?

Christian: This is related to 'monolithique' namespace.
Looking at complex namespaces, like DITA, you have individual modules that could be re-used in different context.
We should see what requirements we have in our case.
Rodolfo: that's what we do with core vs modules
Christian: The proposal is to have formal requirement gathering to see how we name things
Rodolfo: OASIS has some requirements for this.
Only things we can choose are filenames
Fredrik: I think the question is how we split different parts, e.g. have inline tags that could be used in their own namespace.
Rodolfo: Inline Markup SC should provide such info. Currently Yves does the work in core, but that can be changed.
Fredrik: I think it's simpler to keep inline in core, but could be interesting as separate namespace.
Rodolfo: We can change things at any time.
Christian: But we need to have guidelines for this, and for that we would need a set of requirements.
e.g. if inline should have its own namespace, this could guide us on what we can do or not.
Rodolfo: Would you do the gathering?
Christian: Should be join effort
Rodolfo: Anyone interested to lead the gathering of requirements?
Any second for Christian proposal?
It seems there is no momentum for a requirement gathering.
We can table that request for now.


f. Generic mechanism for translation candidate elements and other annotations http://lists.oasis-open.org/archives/xliff/201203/msg00009.html   

Rodolfo: This one is yours too Yves.



g. Minor comments on the specifications http://lists.oasis-open.org/archives/xliff/201204/msg00023.html

Rodolfo: should the source be read-only?
Yves: most wanted read/write
Fredrik: should be modifiable but restricted
Essentially:
- allow to re-segment
- allow to add/remove mrk
- should not add/remove inline codes

Rodolfo: re-segmenting is not modifying the content
Fredrik: There is tags change in some case
But changing span tags is a control process, not a change of content
Steven: do we have a scenario for this?
Klemens: I think source should not be allowed to be modified, better to have a copy and make the change there.
Rodolfo: Currently we can add markup in source
Adding codes in source should be done in original tool
Yves: one scenario is converting content to codes (e.g. properties file with HTML content)
Fredrik: The problem is that the post-processing step is needed
Difference between a controlled process vs a non-controlled process.
We should restrict what possible outside the controlled process.
Rodolfo: So second process could do temporary modifications, but need to restore data afterward.
Helena: first or second process, regardless, meta data would have to flow along.

Klemens: copy is nice because it allows to go back to previous version
Rodolfo: we have no versioning currently
Klemens: from experience: I would not like to see segment to change
For example that breaks matches
Victor: segmentation is part of the process, it doesn't change the source content
e.g. para vs sentence.
In general we should not modify source, but there are cases when tools have too.
In 1.2 we can use a copy, maybe we need to consider this for 2.0 too.
Rodolfo: So copy of original at the unit level.
Victor: Yes, like in 1.2
Rodolfo: We discussed this a while back. Segmenting is moving text, but text is the same.
Anyone else for copy?
Fredrik: Don't see it as useful in long run.
Can't re-use the text except at unit level anyway. It's easy to re-compose the full unit if needed.
Helena: personally, we would find it useful for acquisition content.
Victor: different use cases, we need to cater to all.
Rodolfo: currently we offer that.
Victor: Yes, we have this. But other may need the original content
Could do it different ways. Pre-segment or let CAT tool to segment.
Rodolfo: currently we offer both. Re-segmenting is not changing the content
It moves the content in different parts inside a single unit.

Helena: We do have something called "terminology harmonization" that may change the content.
That is, in the acquisition source, some content may not have any terms.
and we end up coming in have to "harmonmizating" the information
Mostly these scenarios are M&A spaces and change them.

Rodolfo: currently we can add term outside the content
Does it help?
Helena: sort of.
My other thought was also, leave the source read-only and do everything thru pre-and-post processing activities.
Rodolfo: +1 to that
Rodolfo: Maybe changing content before creating XLIFF is the solution

Klemens: Just to understand: You do not want to allow source changing text (e.g. translator sees a typo in the source)
Changing source (also with regard to terminology) means you are doing source work, right? Not in the translation phase?

Fredrik: think we still need to allow add/remove mrk (set comments for example)
Rodolfo: SC will define that.


=== 4/ Sub Committee Reports

--- 1. Inline text (Yves)

Yves: we are working on bidi currently
But the proposal needs data above the inline level
Fredrik: will post the proposal


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

Lucia: Poll about XLIFF tools capabilities is done.
Good answers.
Will need 2-3 weeks before we get the report.



-meeting adjourned