Wiki
To Do

This page lists the items that are still left to do. When an item on the ‘To do’ list has been completed, please move it to the ‘Done’ list.

To Do

  1. requestQuote: Need to finalise exactly what is sent out, and what is returned
  2. requestQuote: Need to finalise and implement the countGroup stuff from the XLIFF group.
  3. requestQuote: Need finalise the exact format of the attachment: do we need to supply a MIME type to distinguish between standard documents, archives, etc.? Or would a URI suffice?
  4. retrieveQuote: Need to finalise the format of the returned quote. Should it be a URI at which the quote can be found, or an attachment? If a URI, we need to worry about security (is it an open link). If an attachment, then we need to worry about the MIME type of the attachment (Word, Excel, PDF, etc.)
  5. acceptQuote: Is a string for acknowledgement sufficient? Should the acknowledgement token be something more permanent?
  6. submitJob: countGroup and attachment stuff, as for requestQuote.
  7. retrieveJobInformation: From Magnus Martikainen: can caller set new requiredBy attribute?
  8. retrieveJobInformation: Review recent changes by Mangus.
  9. retrieveJob: same issue of attachments versus URIs.
  10. rejectJob: Define list of rejection reasons. Create UBL of such reasons.
  11. associateResource: Is it necessary to pass over the MIME type of the resource being attached, or should the resouce server (e.g. HTTP server) provide the MIME type when the resource is being retrieved?
  12. associateResource: Is there any obligation on the part of the client to retain the associated resource at the URI specified, or is the service provider obliged to retrieve that resource, and retain a copy of it locally? In either case, what happens in the event that the resouce (e.g. a TM) changes during the course of a project? Might be useful to have a page providing a more detailed explanation of what happens.
  13. associateResource: Likewise, should the response of this operation provide a new URI where the resouce can be found on the service provider side? If so, do we need to address the security implications of this?
  14. retrieveJobListForResource: Is the URI passed in the original URI from the associateResource operation? If so, do we need to be concerned with whether this resouce is still available at the given URI?
  15. retrieveResourceInformation: This is quite woolly. Do we really need this operation? If so, we must specify more precisely.
  16. General: Need to apply the error messages to the schema.
  17. Suggest that we have a new section of the document on the events history, tying up all of the suggestions made by Magnus.
  18. If we change retrieveResourceInformation to include information about which jobs the resource is used in the retrieveJobListForResource call is not needed. /Magnus


Note added by Magnus Martikainen

From my feedback to the specification in June:


As can be seen above, on of the biggest outstanding issues is that of URIs versus attachments. Check out this page to see a discussion of the various issues.

Done