- From: Felix Sasaki <fsasaki@w3.org>
- Date: Wed, 1 Aug 2012 18:35:28 +0200
- To: Phil Ritchie <philr@vistatec.ie>
- Cc: Arle Lommel <arle.lommel@dfki.de>, Multilingual Web LT Public List <public-multilingualweb-lt@w3.org>
- Message-ID: <CAL58czqFPZT5DA6JMHq2j8Sg_PdtFB5X5XKE1UxP0Puc-tD9-w@mail.gmail.com>
Sure - it's just that we would need to build test cases around this mapping table. What happens in the Okapi / QADistiller row doesn't need to be the same, but at some general level comparable. Felix 2012/8/1 Phil Ritchie <philr@vistatec.ie> > Can we introduce some indirection here: > > Can we make all 26 values normative and publish an annex which to the best > of our abilities would list mappings between ours and any > publishing/consuming tool? > > e.g. > > ITS 2.0 Okapi QADistiller > > Phil. > > > > > > From: Arle Lommel <arle.lommel@dfki.de> > To: Multilingual Web LT Public List < > public-multilingualweb-lt@w3.org>, > Date: 01/08/2012 16:02 > Subject: Re: [ISSUE 34] Potential problem with high-level quality > issues > ------------------------------ > > > > 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 > > > ************************************************************ > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the sender immediately by e-mail. > > www.vistatec.com > ************************************************************ > -- Felix Sasaki DFKI / W3C Fellow
Received on Wednesday, 1 August 2012 16:35:53 UTC