[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [trans-ws] Service Offering
Agreed - most business relationships would have a contract in place, some
with penalty clauses for non-compliance. For quotes, acceptance of a job
would also be based on follow-up activities to check "the story". It would
be foolhardy to misbehave! There's always scope to build a "lie detector"
agent in the future <grin/>
S. Stephen Holmes
Voice: +353-1-605-8087
Novell, Inc., the leading provider of information solutions
http://www.novell.com >>> "Reynolds, Peter" <Peter.Reynolds@bowneglobal.ie> 09/04/2003 12:39:57 >>> 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 -------------------------------------------- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]