RE: [trans-ws] Service Offering

["Reynolds, Peter" <Peter.Reynolds@bowneglobal.ie>]

Hi Gerard,

I am not sure whether we need to deal with the issue of whether or not to
believe what particular vendors are saying they can do or not. There needs
to be some way for the client telling the vendor that they want to get a
quote of a certain type or submit ajob of a certain type. This can be done
by using service offering definitions such as Stephen has outlined. It is
this that is being addressed and not misuse of the system. If we did not use
service offering but had some way where a company created its own
descriptions of whatever they want a quote for, the vendor can still claim
to do it. I suspect it would be a foolish thing to do as it will be quite to
write a routine which only accepts quotes from certain vendors.

Lets talk in more detail about this on Thursday.

Peter.

-----Original Message-----
From: Gerard Cattin des Bois [mailto:gcatt@windows.microsoft.com]
Sent: 08 April 2003 18:54
To: Stephen.Flinter@connectcgs.com; trans-ws@lists.oasis-open.org
Subject: RE: [trans-ws] Service Offering


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