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

Re: [ISSUE-34]: Revised description and example

From: Felix Sasaki <fsasaki@w3.org>
Date: Mon, 6 Aug 2012 14:51:32 +0200
Message-ID: <CAL58czqQmxdphqz6JFcb6q-xkXyt9r+=2d+xd48ZVf2OSZinBg@mail.gmail.com>
To: Yves Savourel <ysavourel@enlaso.com>
Cc: Arle Lommel <arle.lommel@dfki.de>, Multilingual Web LT Public List <public-multilingualweb-lt@w3.org>
2012/8/6 Yves Savourel <ysavourel@enlaso.com>

> Hi Felix, Arle, all,
> A few notes on your example for the languageTool entry:
> -- 1) its-translation-quality-code value
> I'm not sure we should allow a content that is everything and anything
> like in the example.


> To me its-translation-quality-code is a for a code that is basically a
> sub-type, a label that allow a finer granularity of classification of the
> top-level value.
> This way, even if they do not know what the actual value means, tool can
> make a limited use of the data, like present it to the user.
> If we allow anything in the attribute, and use it like a bag of
> tool-specific data it loses all meaning. It seems to me that tool-specific
> data which cannot be mapped to an ITS attribute should be coded by the tool
> using "data-" in HTML5 and a different namespace in XML.
> -- 2) Referenced information vs. inline information
> The LanguageTool element <error> is a good example of why it is important
> to resolve our on-going discussion about how to represent the quality
> information other than inline.
> Arle used <span> to illustrate his mapping, but if LanguageTool was using
> ITS directly it couldn't do it in an XML return file the way it works
> today. Currently our attributes' scope is the content of the element in
> which the attributes are define. In <error> it is not the case. It's more
> like the XLIFF 2.0 case were we must use some non-inline representation
> that refers to the marked up content.
> We need to have either a set of pointers attributes (a lot of added
> complication), or allow the scope of the attributes be interpreted either
> as inline or pertaining to the content that refer to the holding element
> where the attributes are located (or its parent to allow multiple entries
> for the same span of content).
> Maybe it is as simple as to provide the official holder elements like this:
> <its:locQualityNote id='qa123'>
>  <its:entry
>   locQualityType"typographic"
>   locQualityCode="languageTool:UPPERCASE_SENTENCE_START"
>   locQualityComment="This sentence does not start with an uppercase letter"
>  />
> </its:locQualityNote>
> And say that within such construct the attribute don't have an inline
> scope but pertains to the content pointing to that construct.
> In HTML5 we would use the attribute as inline.
> I'm all for using the data category directly in HTML5 documents, but we
> have to realize many tools that produce such QA information are working
> with XML and often bilingual documents, not HTML5.

Arle said today that one use case is to present the quality information in
a browser. Here, with CSS, you can make QA information visible to users
without additional software. From this I understand why the inline markup
has a need. But we don't need to have everything as inline markup - for
CSS, it makes sense anyway mostly for metadata with a closed set of values,
and not for the complex open ended QA information one could produce from
language tool.



> -- 3) Replacements
> I've noticed the "replacements='This'" attribute in LanguageTool.
> This is something we've talked about as well. It seems the attribute
> didn't make it to Arle's table.
> But I believe it is an important information fairly easy to use across
> tools.
> One thing we should maybe take into account would be to allow for multiple
> proposals (e.g. for spell-checking).
> Cheers,
> -ys

Felix Sasaki
DFKI / W3C Fellow
Received on Monday, 6 August 2012 12:51:57 UTC

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