- From: Yves Savourel <ysavourel@enlaso.com>
- Date: Thu, 12 Jul 2012 15:43:24 +0200
- To: "'Felix Sasaki'" <fsasaki@w3.org>
- CC: "'Phil Ritchie'" <philr@vistatec.ie>, "'Arle Lommel'" <arle.lommel@dfki.de>, "'Multilingual Web LT Public List'" <public-multilingualweb-lt@w3.org>
Hi Felix, > I would say: you don't have the issue if it > is not a "ITS only" processor, but an > "ITS in XLIFF 2.0" processor, see my comment > above. That's what I'm saying: The problem is not with the "ITS in XLIFF 2" processor. It's with the basic ITS processor. For example a checker tool that is enabled to read ITS qa-error data category would not handle the XLIFF document, despite the fact it does implements ITS qa-error. >> It may be easier to define 2 local models: >> one inline, one referenced, than try to come >> up with the complex global rules that would be >> needed to map the non-native implementation. > > The question is only: is this needed for ITS in general? Not if you have a global rules for qa-error. > ...wouldn't it be better to come up with a general > solution within XLIFF which is not specific to ITS? Certainly. But then we need global rules, because we should be able to map the ITS-like parts back to ITS concepts (so ITS-only tool can process the file). I'm probably missing something fundamental: So far every ITS data category can be processed by a generic ITS processor. Why suddenly qa-error would not fall into that pattern? > ... is there some hurry about this from the XLIFF side? > I understand the importance of the topic, but isn't the > data category definition we are working on now more urgent? It is about the definition of the data category: Are we going to have a global rule for it or not? All I'm saying is: some formats, like XLIFF2, won't be able to use the local attributes. All the other data categories have a way to 'point' to the equivalent markup. What is that way for qa-error? Maybe the conf-call will help clarify this :) Cheers, -yves
Received on Thursday, 12 July 2012 13:43:58 UTC