[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 --------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]