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

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.
>

+1.


> 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.

Best,

Felix


>
>
> -- 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