Now ISSUE 37 (Re: [ISSUE 34] Quality error category proposal)

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