- From: Felix Sasaki <fsasaki@w3.org>
- Date: Thu, 12 Jul 2012 00:13:49 +0200
- To: Yves Savourel <ysavourel@enlaso.com>
- Cc: Phil Ritchie <philr@vistatec.ie>, Arle Lommel <arle.lommel@dfki.de>, Multilingual Web LT Public List <public-multilingualweb-lt@w3.org>
- Message-ID: <CAL58czrX-iF5gxjF9XJQe6vcKrvAGFF_Q6h1sKGaY1pdPSpQew@mail.gmail.com>
This is now ISSUE-37. 2012/7/11 Yves Savourel <ysavourel@enlaso.com> > > Couldn't you give them a different semantics in the > > "referenced" case, e.g. define a consistent re-naming > > for the semantics you intend? E.g. its:translate for > > the inline case, and itsxliffref:translate for > > the reference scenario? > > I cannot give a different semantic to its:whatever: that's defined by ITS, > not anyone else. > The scenario you have in mind is probably relevant only for the relation to XLIFF. Sure this is important, but I think the semantics need to be defined in agreement between the two groups. > > I could create a new namespace with attributes/elements that implement the > ITS Whatever data category in a way it's useable by reference. And I think > that's what I did in the example with "<xlfQA:qaItem id="qa1" > error????="URI to machine readable information">Should be USB > key</xlfQA:qaitem>". > > We are agreeing here... I think. > > But I'm still not sure this OK from the strict ITS viewpoint. > > First as far as I can tell we don't have global rules for the QA-error > data category so far, but only local attributes. > > So, I cannot use a XLIFF-specific implementation of that ITS data category > and hope to have an ITS processor to understand it 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. > : (there is no way to tell through a rule that xlfQA:qaitem@error is > equivalent to its:qaError). > > Even if we had such global rule. How would we tell that xlfQA:qaitem@errorpertains to the content of the element that references xlfQA:qaitem rather > than the content of xlfQA:qaitem itself? > > Sorry if I'm nitpicking here, but I want to be sure a "referenced model" > is going to work. > > 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? I understand the use case for integration of ITS metadaa into XLIFF 2.0. But adding this functionality to ITS 2.0 in general creates complexity in terms of conformance: who needs to implement this? The integration which is already being prototype between named entity annotation - CMS - Okapi doesn't need that. I really like to stay with the simple, CSS like approach for ITS in general. Also, I would be surprised if XLIFF 2.0 is only looking into ITS tree based metadata (see my other examples in this thread) - wouldn't it be better to come up with a general solution within XLIFF which is not specific to ITS? There is one other question I had asked before: 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? Best, Felix > > Cheers, > -ys > > > > -- Felix Sasaki DFKI / W3C Fellow
Received on Wednesday, 11 July 2012 22:14:13 UTC