Meeting Minutes may-25-2004

["Yves Savourel" <ysavourel@translate.com>]

Here are the minutes
-yves
Segmentation Subcommittee Meeting
May-25-2004


1- Roll Call:
Present: Andrzej, Christian, John, Eiju, Magnus, Tony, Yves.


2- Approval of Minutes from Last Meeting:
	Yves move to accept the minutes, Tony seconded. Minutes were approved.


3- Open Action Items from previous meetings:

	* Andrzej: To investigate further issues related to using SRX with XLIFF.
		Not done yet. To carry on the next meeting.

	* Magnus: To look at pros/cons for send pro-cons for [mrk], [group and trans-unit], and [segment element].
		Email was posted. Tony also posted notes.

	* Yves: To look at pros/cons for [tm namespace]
		Email was posted.

	* Andrzej: To look at pros/cons for [merged attribute]
		Email was posted.


4. Work in Progress - Implementation and Use Cases

4.a) Managing translation of content split across multiple <trans-unit> (Andrzej)

Magnus stated that our previous discussions show use cases that indicate the need for such mechanism. Andrzej explained his view:  There are two cases:
First case - The original source trans-unit are breaking down segment (for whatever reason) and the translator needs to translate into a single trans-unit the text of several. A solution Andrzej uses it ts='merge' to group such trans-units.
Second case - This was also mentioned by John, it occurs a translation is not a direct equivalent of the source. For example when the source text is composed of trans-units of fix lengths, the translation has to flow differently across the trans-unit. Here Andrzej uses ts='noequiv' to indicate the issue.
Magnus noted that having a single mechanism for both case like this would be good. Andrzej concurred and proposed for example a new attribute 'flag' with the values 'merge' and 'noequiv'.
John mentioned that we have already some external reference mechanism that could maybe be used as well. But, as Andrzej noted this wouldn't help for the 'noequiv' case.
John, not an advocate of changing the specification if possible, would favor attribute from a different namespace. Andrzej noted that some application not dealing with segmentation may have to use this too.
Yves said the representation of those cases would probably depend on how we decide to represent the segmentation itself, as a different namespace or not. Tony concurred.
Magnus noted that maybe the merging would be more logically represented by a grouping mechanism. But Andrzej pointed out that it would not address the 'noequiv' issue.


4.b) Discuss pros and cons of suggested segmentation representations:

4.b.i)   <group> of <trans-unit> (Tony)

See: http://www.oasis-open.org/archives/xliff-seg/200405/msg00020.html
Tony suggestion is to use a grouping a metatdata labeling the group as a 'segment-group' for example. One of the main issues would be to break across groups. This can lead to difficulties with merging back to the skeleton file or to build TMs for the file. In addition there is not much validation possible.
Magnus posted also some notes on this topic:
http://www.oasis-open.org/archives/xliff-seg/200405/msg00017.html
He thought that maybe using a new element (e.g. <trans-unit-group>) would be better (clearer).
Both Tony's and Magnus' notes are very similar.
John, looking at Tony's example, mentioned some concerns about using extype as it could be used for other things.
Yves agreed and noted that maybe type could be used as it would affect a group not existing in the original filter output.
Tony concurred, with a new value for type then.
Magnus expressed his concern about transfering meaning from a trans-unit to a group, as it may get confusing.
Tony pointed out that development efforts to deal with a new element or a group with a different meaning would be about the same.
Magnus concurred but liked a new element better because it has a more clear purpose.
The bottom line here would be wether it's better to change XLIFF 1.1 or not.

Tony noted that it would be good to apply each methods to a set of identical examples to see the differences and issues.
Yves and Andrzej agreed. Magnus pointed out that an artificial document may be a good way to start.
Tony said that having as many examples as possible would be great, even better: 'nightmare' scenarii if possible. It was alos pointed out that looking at the life-cycle of the files would help to come up with cases. John noted that such pathological file example can be grown as we go, they eveolved as we try to see how to resolve them.

Andrzej then talked about how to deal with segmenting across <bpt>, <ept>, etc. maybe we need rules set expressing that in some case the segmentation simply cannot be done. We cannot break the well-formness of the underlying XLIFF data.
As a possible solutions, Magnus cited the use of empty <mrk/> elements or the transformation of starting and ending tags into <ph> or <x/> elements that could be reconverted later on.
Andrzej noted that, according his experience, such cases are rare, very rare.
Yves pointed out that they may be more frequent in other formats tha XML: in HTML for example.
Andrzej suggested that normalizing the file may help in some cases.


4.b.ii)  <mrk> in <source> and <target> (Yves)

Yves stated that the <mrk>, <tm:tu> and <segment> proposal were very similar, dealing with segmentation as something happening mostly inside trans-units. The main issue would be, here again, whether introducing a new element or using a segmentation namespace.
Andrzej then noted that one could 'cheat' in some cases as namespaces could be manipulated (e.g. stripped) easily as needed.
Magnus express his desir to see if possible a mechanism that could be validated.

We ran out of time at this point.


4.b.iii) <tm:tu> in <source> and <target> (Yves/Andrzej)

Not discussed directly.


4.b.iv)  <segment> in <trans-unit> (Magnus)

Not discussed directly.


5. Any Other Business

None.

Next meeting in two week from now. June-8.


Action Items:

	* Andrzej: To investigate further issues related to using SRX with XLIFF

	* Andrzej: To post a pathological file un-segmented example.

	* All (volontary): post examnple of nightmare scenarii (un-segmented examples).