RE: [trans-ws] Service Offering

["Gerard Cattin des Bois" <gcatt@windows.microsoft.com>]

Service offering is a good idea. That being said, I am wondering whether any vendor would actually be honest enough to only put what they can handle. Typical vendors' advertizements cover the gamet, and vendors hire external services for what they don't normally provide. How do we know they won't overstate their capabilities just to get past the filtering automation and get a chance to make a bid? 

Misrepresentation is not something we can handle in the context of this effort, but it does beg the question of relevance and usefulness in terms of service offering field.   

Thanks, 
-Gérard 
Gérard Cattin des Bois 
Lead Program Manager, LocStudio Services 
Windows Productivity Tools Team 
gcatt@microsoft.com  (425) 706-1592
Symptom and sign of Inner Peace: An unmistakable ability to enjoy each moment...


-----Original Message-----
From: Stephen.Flinter@connectcgs.com [mailto:Stephen.Flinter@connectcgs.com] 
Sent: Monday, April 07, 2003 9:36 AM
To: trans-ws@lists.oasis-open.org
Subject: [trans-ws] Service Offering


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
--------------------------------------------