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

Re: [ISSUE 34] Potential problem with high-level quality issues

From: Felix Sasaki <fsasaki@w3.org>
Date: Wed, 1 Aug 2012 17:22:04 +0200
Message-ID: <CAL58czpSdpS0iNjUrUBtM7T8zoxwyY4iHjgUS5s5nJzP0Cbf6A@mail.gmail.com>
To: Arle Lommel <arle.lommel@dfki.de>
Cc: Multilingual Web LT Public List <public-multilingualweb-lt@w3.org>
Hi Arle, all,

let me just add that for other data categories, we have only small set of
predefined values - e.g. for "Translate" only "yes" or "no", or for
localization note type "alert" or "description". Also, these values are
distinct - you have either "yes" or "no", so there is no danger of doing
the wrong thing then an application produces or consumes the values.
Finally, the categorization of an error seems to be difficult, with so many
categories being proposed.

This situation led me to the thinking that we should set a high bar for the
normative values - otherwise there won't be any interoperability of what
implementations produce or consume, as Arle described. I don't see a clear
way out, and I'm looking very much forward to feedback from implementors -
Yves, Phil etc.



2012/8/1 Arle Lommel <arle.lommel@dfki.de>

> Hello all,
> I was discussing the high-level quality issues with Felix this morning and
> we have an issue. If they are to be normative, then we will need to find at
> least two interoperable implementations *for each value*, not just for
> the mechanism as a whole, and to test those implementations against test
> cases. While that would not be hard for some like *terminology*, it would
> be difficult for others like *legal*, because, while they are used in
> metrics, they are not particularly embedded in tools that would produce or
> consume ITS 2.0 markup.
> One solution is to put the issue names in an informative annex and *very
> strongly recommend* that they be used. That approach is, I realize,
> unlikely to satisfy Yves, for good reason: if we cannot *know* what
> values are allowed in that slot, then we cannot reliably expect
> interoperability. At the same time, if we only go with those values for
> which we can find two or more interoperable implementations, that list of
> 26 issues will probably become something like six or eight, thereby leaving
> future tools that might address the other issues out in the cold.
> I have to confess that I do not see a solution to this issue right now
> since we really need the values to be normative but if we cannot test them
> in fairly short order they cannot be normative. The test cases must be more
> robust that simply seeing that a tool identifies an issue and passes it on:
> we also need to see that they do this consistently with each other, which
> is hard since the set of issues from the various tools only partially
> overlap.
> If anyone has any brilliant ideas on how to solve the issue, please feel
> free to chime in. We're still working on this and hope to find a way to
> move forward with normative values.
> Best,
> Arle

Felix Sasaki
DFKI / W3C Fellow
Received on Wednesday, 1 August 2012 15:22:37 UTC

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