[no subject]

Minutes:
1/ Roll call
Present: Andrzej, Stephen, Magnus, Peter.
Apologies: Reinhard

2/ Minutes of the last meeting could not be read due to an issue accessing the OASIS KAVI site. They will be agreed at our next meeting.

3/ Completion of Draft specification 
Discussion based on To-Do list 
http://212.147.140.51:2500/wiki/show/ToDo

9.	retrieveJob: same issue of attachments versus URIs. 
meeting: This has been resolved by use of URIs.

10.	rejectJob: Define list of rejection reasons. Create UBL of such reasons. 
It was agreed that this call would have the Job-ticket and the rejection details. meeting: There will not an additional reason parameter.

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? 
meeting: It was decided we will no longer pass a Mime type as we are not using attachments.
The notes parameter would be renamed ‘reason’ and would include infromation on what the resource was being used for.

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. 
meeting: We recommend that the URI for a resource should be retained for the length of the project.
A modified resource can be located at the returned URI.

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? 
meeting: Security issues will be dealt with by using other standards.

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? 
meeting: This will be removed from the Spec.

15.	retrieveResourceInformation: This is quite woolly. Do we really need this operation? If so, we must specify more precisely. 
meeting: The URI used in the call can be the source URI or the returned URI. The parameters returned are: 
* Job ticket(s)
* purpose – same as in associateResource
* source URI
* returned URI

16.	General: Need to apply the error messages to the schema. 
meeting: Stephen will apply this.
17.	Suggest that we have a new section of the document on the events history, tying up all of the suggestions made by Magnus. 
meeting: Magnus volunteered for this.
18.	If we change retrieveResourceInformation to include information about which jobs the resource is used in the retrieveJobListForResource call is not needed. /Magnus 
meeting: This will return a lsit of URIs
Andrea talked to the UBL people about extensions and they suggested that we use private areas for user defined codes.

4/  AOB
Gerard has announced that he has resigned form the TC. Peter pointed out that this resignation and Stephen leaving will have a significant effect on our TC and we might want to consider our options for how we continue our work. This will be discussed at our next meeting.
Stephen said that this might be his last meeting. The TC paid thanked him for his work and technical leadership of the committee.

5/ Next meeting: December 9th 2004

View event details:
http://www.oasis-open.org/apps/org/workgroup/trans-ws/event.php?event_id=6448

PLEASE NOTE:  If the above link does not work for you, your email
application may be breaking the link into two pieces.  You may be able to
copy and paste the entire link address into the address field of your web
browser.