Re: [ISSUE-34] Draft of quality section

2012/8/6 Yves Savourel <ysavourel@enlaso.com>

> > If the whole is locQuality (and it is the data category),
> > then what are the individual bits (locQualityNote, locQualityType, etc.)
> > called?
> > ...
> > Any ideas?
>
> To me they are simply different information pieces for the Localization
> Quality data category. Maybe "parameters", but that is a bit overloaded.
> "Options" is another possibility, or "fields", or "facets", or "metadata".
>
> Or maybe we just don't give them a name. Other data categories like
> "Entity" have many options like this and don't seem to need a specific name.
>

I would say "Entity" is the only case in which you have a lot of "options".
And that is why I asked Tadej at
http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Aug/0073.html
to be more specific about what is mandatory and what not. Otherwise, you
would end up with rules like
<its:disambiguation selector="/text/body/p[@id='dublin']/>
that don't make any sense.

In ITS 1.0 we were very careful not to allow implementations to say "I
implement the localization note data category globally, and I implement
only locNote and locNote ref, but not locNotePointer or locNoteRefPointer.
This is very helpful for interoperability. If application A (or a human)
creates localization note metadata and sends it to implementation B that
claims "I implement the localization note data category globally",
application A can be sure that all localization note metadata will be
processed by application B.

I want that clear picture for ITS 2.0 too, and not introducing options of
what an application processes and what not.

Compare this to CSS: an application that claims to implement vertical align
needs to process all values - top, middle, bottom, baseline, sub, super,
text-top, text-bottom. It creates confusion for (web) content authors if
they would need to check for each browser whether they can use one of these
values or not. (In some cases, they have to do that, but this is a bad
thing and browser vendors are working hard on getting this right.)

So the main question is if we agree on above approach?

Now, coming back to quality ...
I would like to say: each tool that claims to process global or local
quality information processes all attributes. This does not mean that in
the attributes are always present. But we shouldn't allow tools to pick a
few attributes and do nothing with others.
To make expectations clearer, I would say in the "implementation"
subsections the following:


loc-quality-profile: mandatory; if human check, have a dedicated URI for
that

loc-quality-score: mandatory, value is 0-100 or "unknown"

loc-quality-type: mandatory, value is "unknown" or what Arle had in the
table "permissive values"

loc-quality-comment: optional

loc-quality-severity: mandatory, value is "unknown" or what Arle had in the
table "permissive values"
Best,

Felix


>
> -ys
>
>
>


-- 
Felix Sasaki
DFKI / W3C Fellow