W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > July 2012

RE: [ISSUE 34] Quality error category proposal

From: Yves Savourel <ysavourel@enlaso.com>
Date: Wed, 11 Jul 2012 19:20:18 +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>
Message-ID: <assp.0539053bc9.assp.0539f768cc.00b001cd5f89$72dbd420$58937c60$@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.

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: (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@error pertains 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.

Received on Wednesday, 11 July 2012 17:20:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:31:47 UTC