TIPP: Clean up PackageCreator/ResponseCreator XML Schema Structure

[GoogleCodeExporter]

The organization of the Task/Response portions of the schema are seem like they 
could use the polish.  Two specific issues jump out:

1) The PackageCreator element of a response package is *not* the creator of 
that package -- it's actually the creator of the original request package. The 
response creator information is actually stored in 
OrderResponse/ResponseCreator.  This seems unintuitive to me.

2) PackageCreator and ResponseCreator store the same information, but are 
different schema types use different child elements.  They should be unified to 
a single schema type.

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

[GoogleCodeExporter]

Comment from Joerg via email:

The confusion depends on how we read the description: in the current scenario
we have an original package creator who initiates a task request, and a
respondent who after fulfilling the requested task either reports success or
failure, and extends the package with result objects. In this sense, the
respondent may not be seen as a package creator, and the package itself gives
us information about the (orginal) creator, the task, the task-associated
objects, the respondent (at least the packer of the result objects), the final
task state, and the resulting objects. Yet another possibility would be to use
besides "creator" an additional "addressee", i.e.
<GlobalDescriptor><PackageCreator> ... </PackageCreator><PackageAddressee> ...
</PackageAddressee><OrderAction> ... </OrderAction></GlobalDescriptor>. In this
scenario we would not need the ResponseCreator, and a possible check could be
that PackageCreator and PackageAddressee have been switched (to ensure at least
sort of control which currently is not possible because we don't maintain any
state information for a requested task).

Original comment by tingley on 27 Jan 2012 at 7:51

[GoogleCodeExporter]

Further comments, from the email thread:

2) I think one of the early TIPP drafts included an addressee, and I argued for 
its removal on the basis that the receiving end it not always known when the 
package is generated.  I still feel this way.  

However I'm not happy with the current format.  One property about your 
addressee proposal that I do like is that in the response package, the name of 
the response creator (aka the original addressee) comes first in the package.  
This just seems like a nicer, more intuitive structure for the package.  It's a 
bit of a nod to human readability, since a machine doesn't care, but I think it 
improves clarity a bit.

I think ultimately, it's a question of how we see the response package.  Is the 
response best thought of as:
- Some extra elements that are wedged into the request package, while most of 
the request is left untouched?
- or, as a separate package that happens to be a response?

(What I'm trying to explain is that there's a conceptual difference here, even 
if the practical impact is small.)

Since the response package has its own package ID, it seems to me that the 
second way of looking at it is more intuitive.  In that case, a structure like 
this might make more sense:

<TIPManifest ...>
  <GlobalDescriptor>
    <UniquePackageID>[response id]</UniquePackageId>
    <PackageCreator>[Information about the creator of the response package]</PackageCreator>
    <OrderAction>
      <!-- Note, <OrderTask> is now only used in task packages; see OrderResponse/InResponseTo -->
      <OrderResponse>
        <InResponseTo>[Information about the original request, including information about the request creator]</InResponseTo>
        <ResponseMessage>...</ResponseMessage>
        <!-- Comment, etc -->
      </OrderResponse>
    </OrderAction>
  </GlobalDescriptor>
  <!-- ... rest of the package -->
</TIPManifest>

In other words:
Top-level package creator info is always the info for the creator of the 
package itself
OrderAction now contains either an OrderTask or an OrderResponse
OrderResponse encapsulates the task data it's a response to in a child element
What do you think?

Original comment by ch...@spartansoftwareinc.com on 1 Feb 2012 at 8:18

[GoogleCodeExporter]

And Joerg's response:
Add 2) In principle I agree with you suggestion of the new information 
distribution because it also allows for a kind of traceability of a package 
exchange. In particular when supported by hyperlinks which permit a reference 
to the origin of a package request, and even chains of request/response routes. 
So it is also a possible way to introduce transitivity (another long-term 
goal). Conceptually, we would therefore maintain the second view with the 
addition of a fully fledged hyperlink scenario. By going this way, we also 
would not inflate the package with data objects (request data, response data) 
because only the necessary data that represents the package type (request or 
response) is part of the package, however, with the possibility to have the 
"complete" data set through the maintained hyperlinks.

Original comment by ch...@spartansoftwareinc.com on 1 Feb 2012 at 8:18

[GoogleCodeExporter]

Sample reworked <GlobalDescriptor> from a response package:

  <GlobalDescriptor>
    <UniquePackageID>urn:uuid:84983-zzz-0091-alpppq-184903b-aj1239</UniquePackageID>
    <!-- This is the information about the creator of this package -->
    <PackageCreator>
        <Name>Joe the Freelance Translator</Name>
        <ID>http://joestranslations.biz</ID>
        <Update>2011-05-18T19:03:15Z</Update>
        <Tool>
          <ToolName>Kilgray MemoQ Standard Edition</ToolName>
          <ToolID>http://www.kilgray.com</ToolID>
          <ToolVersion>6.0</ToolVersion>
        </Tool>
    </PackageCreator>
    <OrderAction>
      <OrderResponse>
        <!-- The Response information just repeats what the task was -->
        <TaskType>http://interoperability-now.googlecode.com/schema/tasks/v1/translate</TaskType>
        <SourceLanguage>en-US</SourceLanguage>
        <TargetLanguage>fr-FR</TargetLanguage>
        <!-- Now describe the package we're responding to, using its
            - ID and creation information. -->
        <InResponseTo>
          <UniquePackageId>urn:uuid:12345-abc-6789-aslkjd-19193la-as9911</UniquePackageId>
          <PackageCreator>
            <Name>Welocalize</Name>
            <ID>http://w01.welocalize.com/globalsight</ID>
            <Update>2011-05-09T22:45:00Z</Update>
            <Tool>
              <ToolName>GlobalSight 9.0</ToolName>
              <ToolID>http://www.globalsight.com</ToolID>
              <ToolVersion>9.0</ToolVersion>
            </Tool>
          </PackageCreator>
        </InResponseTo>
        <!-- Now describe the results -->
        <ResponseMessage>Success</ResponseMessage>
        <ResponseComment>Everything went fine.</ResponseComment>
      </OrderResponse>
    </OrderAction>
  </GlobalDescriptor>

Original comment by ch...@spartansoftwareinc.com on 1 Feb 2012 at 11:43

[GoogleCodeExporter]

Fixed in 1.4 

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

• Changed state: Fixed