1. Query Support
This returns the type of translation service supported by this Vendor (languages/quality/TM used etc.). 

The information should be returned in XML format for ease of parsing/display, and should be organised as follows -
Language Supported. For each -
File Types supported in this langauge
Quality of translation options available for this language
Per word cost for each
Is Machine Translation supported for this language
Can it be used in conjunction with human translation
Estimated per word cost ?
Is Translation Memory Supported
Will the Translation Vendor host this (i.e. maintain on a per project/company basis)
Will the Translation Vendor accept an upload of existing TM's
Will the Translation Vendor download the translated TM to you
Format(s) supported
Text description of TM policy
	Stages of review allowed (eg. none, basic, legal, graphics)
	Estimated turnaround time ? per word ?

2. Request Quote
This is the point at which meaningful information about the job is needed by the system in order to estimate costs. Two formats (i.e. two methods) should be available, however the first format may not produce a binding quote. In either case, in returning a job-ticket to the user, the Service should also specify an expiry date/time for the quote.
A. Request based on wordcount and filetype

Passed In
Project Information/Ticket ?  Session handles Company info ?
Total Word Count
Mime-type of data
Quality (as defined in 1. Query support)
TM/MT information
Returned
Job-ticket
Estimated cost (including appropriate currency information)
Expiration date of quote
B. Request based on file

Passed In
Project Information/Ticket ? Session handles Company info ?
File upload information (see Upload section)
File mime-type (may be XLIFF)
TM upload/reference information (see TM section)
Returned
Job-ticket
Estimated cost (including appropriate currency information)
Expiration date of quote
Note : in the case of an uploaded XLIFF job, there may be a case for including per-item information

3. Reject Quote & Re-quote
Using the job-ticket, the quote may be rejected and the job implicitly removed. We may need a facility to re-quote based on a different quality option and/or use of TM & MT. We don't want to re-upload the job in this case.

Passed In
Job-ticket
reject/requote information ?
Comment on rejection reason ?
Returned
acknowledgement

4. Accept quote
Using the Job ticket a quote may be accepted, thereby initiating translation of the job. Payment details in the form of either Purchase Order or Credit Card Info should be supplied.

Passed In
Job-ticket
Financial information. One of -
Purchase Order (from recognised supplier)
Credit Card Information
Other . . . ?
Notification information (see Notification section)
Upload information (may be required if 2.A is used rather than 2.B above)
Returned
Acknowledgement of job initiation

5. Do translate
Alternatively to 2,3&4, where a relationship already exists, or the cost is prepaid for all required translations, or perhaps the translation service is deployed in-house and is a MT engine, there may be a case to simply call translate as the quote/accept mechanism isn't required.

Passed In
Job-ticket
Notification information (see Notification section)
Upload information
Returned
Acknowledgement of translation initiation

6. Cancel/Suspend
The Client may request that any job being translated be cancelled/suspended. This is a request only as the service cannot gaurantee to comply with this immediately, depending on job-state etc. and there may still be a cost incurred. Cancel/Suspend should fail if translation is complete. The current job status should be returned also.

Passed In
Job-ticket
Returned
Success/Failure
Job Status (see 6. View Job Status)

7. View job status
At any stage the status of any job should be viewable. This should have typed information (that we can understand) and free format (eg. HTML page)

Passed In
Job-ticket
Returned
Current Stage (TM, MT, HT, Verification, QE, Graphics Review etc.)
Current Status (eg. Error, ok, unknown)
Free format HTML (or possibly URL for retrieval)
Should be flexible

8. View jobs by company/project/other
A client needs to be able to view outstanding or completed jobs by company/project/state etc. This needs to be flexible enough to handle new categories. But the basic views should be as described below

Passed In
View required - eg.
For specified user
For specified company
For specified project
All of the above by specified state
Returned
A list of job tickets complying with the query
Basic information about each job  - possibly up to the level of that returned by 6. View Job Status

9. Download Translation
Any translations completed obviously need to be downloaded based on the Job ticket.

Passed In
Job-ticket
Returned
The downloaded file. see the Download section for details.
The timeout for acceptance ?
The responses actions recognised (see 9. below)

10. Reject/Respond to translation
You can rejectBased on Structure ? Quality ? Content ? Other ?

Passed In
Job-ticket
Rejection reason
Request redo ?
Returned
The downloaded file. see the Download section for details.
review translation ?
redo translation ?

11. Upload populated TM
If translations have already been done in house (or by another vendor), then you will need the ability to upload translation memory for a particular job/project. You should specify the type of Translation Memory and a name, (and receive a TM ticket for it for future reference?).

Passed In
Project  (or job-ticket ?)
TM upload details
TM name
Returned
Acknowledgement
A TM ticket ? (name could be used)

12. Download populated TM
Given the ease of selecting a preferred translation vendor, Clients will want to re-use translations, so we will need to add the ability to download TM