TIPP: Partial completion of packages

[GoogleCodeExporter]

The current spec mandates that only two outcomes are allowed in a response 
package: success and failure.  The criteria for success of a translation task 
currently requires that all input files be processed to output.

Micah and others have observed that this is overly restrictive.  Currently, if 
an input file type can't be processed by a given system, the entire package 
must be rejected.  It also prevents any meaningful processing of portions of 
package content when, for example, a single object is corrupt or invalid.

This seems harsh.  Would it make more sense to allow completion to be indicated 
per-object?

Original issue reported on code.google.com by tingley on 24 Jan 2012 at 10:09

[GoogleCodeExporter]

A more robust completion model may also lead us in a direction away from 
hardcoding "Success" and "Failure" as package-level status in favor of 
something more fine-grained or even something defined per-task.

Original comment by tingley on 24 Jan 2012 at 10:12

[GoogleCodeExporter]

Original comment by tingley on 24 Jan 2012 at 10:19

• Added labels: Priority-High

[GoogleCodeExporter]

Based on discussion with the group, the approach taken in 1.4 is to limit 
"Success" and "Failure" to determinations about the transport layer itself, and 
to leave determinations about (for example) the extent to which the content was 
actually translated to higher level metadata that is better equipped to deal 
with it.

The "Processing Expectations" section from the "Translate" Task Type provides a 
fuller explanation, which I'm pasting in here:

A system that generates a Translate request package expects a basic translation 
process to have been performed on the XLIFF:doc that it receives back as part 
of a successful Translate response.  However, it is not a requirement that the 
translation be “complete” in order for the response to report 
“Success”.   There are several reasons for this:
* “Completion” is a subjective term when dealing with a bilingual file 
format, and it would be difficult to accurately evaluate it via automation.  
For example, in one context an empty target TUV could be considered an error, 
while in others it might be the intended “translation” of source text that 
does not appear in the translation.
* It is a common use case in enterprise environments for a translator to 
complete a large translation task incrementally, by repeatedly downloading 
content for offline work and then uploading the completed portion at the end of 
the day.  Requiring the entirety of the XLIFF:doc to be translated for a 
successful response would preclude using the Translate task in this case.
* The per-TUV state stored within an XLIFF:doc is both a more powerful and a 
more natural place to track translation progress.

“Success” Response

A “Success” response indicates that the request was successfully processed, 
and that translation activity may have been performed.  The XLIFF:doc file 
should be examined to determine whether the translation is complete.

“Failure” Response

A “Failure” response indicates that the request was not successfully 
processed, for instance due to:
* Invalid TIPP manifest data, package structure, or security information
* Invalid, corrupt, or missing XLIFF:doc file
* Software error

When possible, the ResponseComment element should be used to provide additional 
information about the failure, such as an error message or stack trace.

Original comment by ch...@spartansoftwareinc.com on 1 Mar 2012 at 8:30

[GoogleCodeExporter]

Fixed in 1.4

Original comment by tingley on 18 May 2012 at 2:14

• Changed state: Fixed