Service Offering

[Stephen.Flinter@connectcgs.com]

All,

in preparation for the next Translation web service TC meeting this week,
Peter asked me to prepare a short summary of the discussion around service
offering.

For those of you unfamiliar with the issue, my original post on the topic
can be found at:
http://lists.oasis-open.org/archives/trans-ws/200302/msg00009.html

1. Introduction

Working from Bill Looby's original document, one of the issues that arose
very early on in the discussion about the web service standard for
translation was what types of information should be provided by the Query
Support operation.  Bill's the original proposal has items such as:
      language supported
      file types supported
      quality of translation options
...and so on (I'm not going to reproduce the list here).

One of the items that I (and others) felt was missing from the data
returned by the Query Support operation was that of service offerings.
That is, a description of what services the localisation vendor was able to
offer to the client of the web service.  I volunteered (in cooperation with
Stephen Holmes of Novell) to put together a list of possible service
offerings.  Examples of such service offerings would be "translation",
"engineering", "test", etc.

2. Rationale

The rationale behind the concept of service offerings is that there is more
to localisation than language translation.  Particularly in the software
world (but also in other business domains) localisation in its broadest
sense refers to things like:
      engineering - where a l10n vendor has to perform a significant amount
of software engineering on a product before the text can be translated
      quality assurance - where a l10n vendor has to perform functional
tests on the product after it has been localised (to ensure that the l10n
process has not corrupted the product).

The services that a vendor may offer may also include relatively esoteric
items like screen-shooting.  This is where screenshots of a product would
be made after the product has been localised for inclusion in the manual or
online help.

In the document attached to the mail referenced above, we have categorised
the service offerings at two levels.  The high-level offerings are:
      Engineering
      Admin
      Build
      Quality Assurance
      Translation
      Online help
      Documentation

The document then lists a set of more detailed offerings, each within one
of the high-level offerings listed above.

3. Debate

OK, so that is the state of play at the moment.  From this, I believe the
issues to be debated at the next TC meeting are:

i) Do we want to make reference to service offerings at all?
ii) If so, do we want to keep the list quite short (e.g. just the seven
high-level offerings listed above)
iii) ...or do we want to make the list exhaustive (e.g. the full list
offerings in the document).
iv) ...or do we want to make it completely free-form, and up to the service
provider to determine
v) If we go for one of the first two options above, in the Translation WS
standard that we product, do we want to give each of the offerings a
defined semantic meaning (e.g. the "translation" service offering means
exactly this, and no more ....)
vi) Do we want to make the list extensible, to allow vendor specific
service offerings to be included?  If so, what is the implication of this
from the client's point of view
vii) Do we want to support the service offering concept in other web
service operations, or just the Query Support one?
viii) If yes to the latter, what do we need to do to support the service
offering concept in the other operations (e.g. Request Quote, Do Translate,
View Job Status particularly).
ix) How do we strike the right balance between simplicity (to understand &
to implement) and comprehensiveness?
x) What part, if any, does ebXML have to play in this?

4. Benefits

Of the above questions, the most important is probably point (i) - do we
want to utilise the concept of service offerings at all.  I believe that we
should, for the following reasons:

i) Localisation is more than just translation, and it is useful (or,
indeed, essential) for customers to be able to determine what services are
on offer from their (potential) vendors.
ii) When quoting for a project, it is important for a vendor to know
exactly how much work the customer wants them to do.  Just knowing word
counts will not be sufficient for this.
iii) It will be critial to define the area of service offerings if we are
ever to move towards a supply-chain management (SCM) type of business model

5. Downsides

Some of the potential downsides of this approach are:

i) Additional complexity to support the service offerings parameters
ii) Potential for ambiguity if we're not careful - translation may mean
different things to different people
iii) Difficult to get a canonical list of service offerings that everybody
can agree on.

---------------------------------------------
Stephen Flinter
Connect Global Solutions
[t] +353 (0)1 882 9038
[f] +353 (0)1 882 9050
[m] +353 87 798 1228
[e] stephen.flinter@connectcgs.com
[w] www.connectcgs.com
--------------------------------------------