Re: [ISSUE 34] Quality error category proposal

Hi Yves, all,

2012/7/11 Yves Savourel <ysavourel@enlaso.com>

> Hi Felix, all,
>
> We’re painfully aware of the drawbacks of “overlap” solutions in XML. But
> there is no way around having them in XLIFF. So, as you say, the solution
> would be to reference some kind of ‘holder’ element and have the ITS info
> there.
>
> The main problem with using the same attributes both in the "inline" and
> in the "referenced" notation is that the same ITS attributes would need to
> have two different semantics.
>


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 think the key of getting interoperability between ITS (and probably many
other pieces of "inline" metadata) and the "reference" XLIFF 2.0 flavour
would be to separate the conceptual definition from the actual
implementation - like we do in ITS 1.0. Saying "translate has the values
yes or no". The usage of "translate" as inline attributes is an aspect that
could be separated. Also, in that flavour, you probably also wouldn't use
global rules, since they just don't fit to the reference scenario.

It's not nice, as you say, but as I understand it both language technology
applications and localization of (HTML5) Web content "as is", that is
without conversion to XLIFF, is getting quite some uptake too. So I would
try not to change the "inline" version of ITS, but have a clear distinction
to the XLIFF reference approach. And, maybe fleshing out that distinction
can that, after we have decided about our data categories to tackle (end of
July), and have put some details into the spec (I hope by early September).
Or is there some hurry about this from the XLIFF side?

Best,

Felix



>
> - In the inline case the information applies to the content of the element
> where the attribute is. That's the normal and expected behavior:
>
> <span its:term="yes" its:locNoteType="alert"
> its:locNoteDescription="...">...</span>
>
> - but in your converted notation, the information applies instead to the
> content of the element that references the element where the attributes are:
>
> <metadata id="itsinfo" its:term="yes" its:locNoteType="alert"
> its:locNoteDescription="...">
>
> Currently we can't have it both ways.
> We would need to specify that difference explicitly somehow. And I'm not
> sure it would be a good solution.
>
>
> Another problem is that if ITS doesn't define some 'holder' element for
> the QA-errors (I guess there is always <its:span>, but it doesn't feel
> right to use for this. So I suppose one could be provided, but that's a
> rather awkward solution.
>
> This drives me to think one may as well define the whole data category in
> an XLIFF module.
> I suppose that's fine. It would be something like this:
>
> <unit>
>  <segment>
>   <source>...</source>
>   <target>Insert the <mrk id='m1' type='x-xlfQA' ref="#qa1">Pen
> Drive</mrk> in the USB port</target>
>  </segment>
>  <xlfQA:qaItem id="qa1"
>   error????="URI to machine readable information">Should be USB
> key</xlfQA:qaitem>
> </unit>
>
> It's a bit sad to have to use a namespace and structure that's not
> 'natively' ITS.
>
> But there is something worst:
>
> This means we would have to define global rules to allow ITS processor to
> map such data back to the qaError data category. Maybe that is something we
> were planning to have anyway? But I haven't seen it in any example so far.
>
> Cheers,
> -ys
>
>
>
>


-- 
Felix Sasaki
DFKI / W3C Fellow