TIPP: Should translate-native-formats return a TMX?

[GoogleCodeExporter]

Micah posed this devious question in re: the 1.4 spec:
- What do I do if I send out a package, and want to get back target files, and 
a TMX with the completed translations? We used to do this, and I think a lot of 
places still work this way. On page 14-15, it says the TMX is optional in a 
response, and implies that the TMX section is purely for outgoing (reference), 
and not for capturing the results of the project.

This is mostly a matter of the translate-native-formats task type.  For the 
translate-*-bitext task types, I think it's an acceptable solution to just say 
that the translations are in the target tuvs of the response bitext, and the 
TMX can be extracted from that by the receiver if necessary.

For translate-native-formats, it's another question.  Extracting TMX from this 
is non-trivial (it requires alignment), so there would be real value to 
returning the TMX as well.  So, there are three options:
1) translate-native-formats response DOES return the TMX of translations
2) translate-native-formats response DOES NOT return the TMX of translations
3) it's optional

Solutions 1 and 2 are both limiting in their own ways.  But #3 would lead us to 
another choice.  Because the need for TMX in the response would be driven by 
the requesting party, we'd either need to:
a) split translate-native-formats into two task types, one which returns TMX 
and one which does not
b) add some sort of parameter system

Neither of these is a great solution, although a) is simpler.

Original issue reported on code.google.com by tingley on 30 Mar 2012 at 4:18

[GoogleCodeExporter]

So either we have another boolean flag, "include-tmx-in-response" (etc), or we 
have translate-native-formats and translate-native-formats-return-tmx? 

Splitting the tasks seems clumsy, but I would be ok with it either way. 

Original comment by micah...@gmail.com on 30 Mar 2012 at 1:34

[GoogleCodeExporter]

Right.  I've been steadfastly opposing suggestions to add top-level flags like 
include-tmx-in-response.  The other way to handle it would be to let the task 
type specify some set of parameters like this:
<Task>
        <TaskType>http://interoperability-now.org/TIPP/schema/tasks/v1/translate-strict-bitext</TaskType>
        <SourceLanguage>en-US</SourceLanguage>
        <TargetLanguage>fr-FR</TargetLanguage>
        <Argument name="include-tmx-in-response" value="true" />
</Task>

Then the task type definition can specify what (if any) argument name/value 
pairs are allowed.

This is equivalent to just forcing all the tasks to be enumerated, it's just 
more concise.

At this point, I am tempted to just split the tasks.

Original comment by tingley on 30 Mar 2012 at 5:21