Meeting Minutes - Aug 24.

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

Here are the minutes:
-yves
Segmentation Subcommittee Meeting
August-24-2004

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


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


3- Open Action Items from previous meetings:

	* All (volontary): post examnple of nightmare scenarii (un-segmented examples).
		Magnus would like concrete examples. Andrzej mentionned that an example of "pathological" file with text difficult to segnment would be useful. Magnus will check with Trados Q&A dept.



4. Work in Progress - Implementation and Use Cases

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

Magnus summarized the case, which is basically when the target is not a representation of the source.
Andrzej cited the example of VoiceXML where in some cases the target has more entries than the source becuase of gendre. He said we needed to come up with some recommendation for a 'noequiv' and 'merge' attributes to main TC, as this is a concern even for un-segmented text. Magnus noted that we had decided to include this in our recommendadtions.



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

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

Tony summarized this case. It's just an alternative to creating new elements, by breaking a single <trans-unit> into many, grouped inside a <group>. We may need some kind of new flag to indicate that all translation unites are the original same translation unit, so it can be merged correctely.


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

Yves summarized this case. He stated that the <mrk>, <tm:tu> and <segment> proposal were very similar, dealing with segmentation as something happening mostly inside trans-units.
Magnus noted that here the main issue would be how to deal with exitisng inline codes (e.g. <bpt>) when they gert broken down.
He suggested, with Andrzej, that a possible solution would be to change them to <x> or <ph>.
Magnus also suggested that we could be using <mrk/> (basically an empty element) to work-arround the problem.

Related to the restructuration of <trans-units> Tony expressed the concern that we could have overlap across two files and needed to make sure it did not happend.


4.b.iii) <tm:tu> in <source> and <target>

Andrzej summarized this case. Magnus noted that it was offering the same issues as for <mrk> (need to change existing inline tags). Andrzej mentionned that we needed to make sure to end-up with well-formed files. He was happy with this solution because it fits in his overall architecture, using "pipped" processes.


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

Magnus mentionned that it was important to be involved in the general discussion about extension points in <source> and <target> in the main TC. He noted that the current trend seems to be to use <mrk> or <g> for this. Andrzej agreeded.

Magnus noted that the boundries set by the <trans-unit> were important. Andrzej agreeded and noted that we could have solution with attributes that would qualify the translation units (e.g. noequiv, etc.). Magnus underlined the importance of the fact XLIFf being an interchange format.

Magnus summarized the two main views:

1) transformation of the content (e.g. new trans-unit, or element)
2) use of markers inside <source> and <target>

Both solutions have problem when there are inside inline tags. A possible solution would be to have a mechanism to keep track of the data. A second idea is to use empty markers (e.g. <mrk/>). But this would bring validation problems and a weaker relationship between source and target.
Andrzej said that using tm:tu seemed a natural way of doing it. Tricking an XLIFF file to be an normal xml file.
Tony leans toward a solution based on transformation. It looks cleaner.
Yves leans toward markers inside the <source> and <target>. but he's without strong opinion.
Eiju underlined that fact that the correspondance source/target is important, and we have cases of joining or splitting trans-units.
Christian is worry a bit about having different XLIFF files with different structure but same content.

Andrzej asked if we would/could bringing to the main TC the issue of attribute.?
Tony said we should formulate it better the things we want to submit.

Christain express concerns about adding new attrributes. He mentionned that using a namespace at first may be easier,
Tony agreeded that such chjange would require a change of version. 



5. Any Other Business

None.


Next meeting is the second Tuesday of Septembre (Sep-14)


Action Items:

	* M: summarize the approaches