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

[ISSUE 34] Quality error category proposal

From: Arle Lommel <arle.lommel@dfki.de>
Date: Tue, 10 Jul 2012 16:22:59 +0200
Message-Id: <D2D877CB-EB7F-4F71-B45F-C4A24BF7D439@dfki.de>
To: Multilingual Web LT Public List <public-multilingualweb-lt@w3.org>
Felix and I have been discussing the QA error categories and think there is a way to simplify it considerably and lower the bar to implementation.

Example:

<p>Insert the <span
                                   its-error="yes"
                                   its-errorinfo="Should be USB key"
                                   its-error????="URI to machine readable information">
Pen Drive</span> in the USB port</p>

In this model we drop the whole category for declaring what model you use or information about the quality of the whole document. Instead we have three attributes:

its-error: yes|no
Identifies whether the element is an error or not. Default = no. (I don't see that you'd ever explicitly set this locally for a value of no, but you could, in theory.

its-errorinfo: plain text
Contains human-readable information about the error. For example, Yves' tool could pass on its user error messages for consumption in this.

its-error????: URI
Contains a link to machine-readable information about the error. What that information is we have yet to work out, but it could include a pointer for the definition, the severity, etc.. Note: We need a name for this, but we don't have a good one yet.

The advantage to this approach is that implementation is easy and we leave out the difficulty of the machine-readable part, which we have to define in another project I'm working on, so we don't have to wait. The minimum implementation requirement is just to tag the error, e.g., <p>Insert the <span its-error="yes">Pen Drive</span> into the USB port.<p>. To move up a level of complexity you could add a human-readable error message. To go more complex, we deal with the machine-readable stuff when it is ready.

Any thoughts? Note that this drops most of the in-document complexity of the previous proposal in favor of a simple, lean syntax in the document and we can deal with the complex stuff more at leisure.

Note to Yves: Your point about needing to define what is pointed to is well taken. We don't want to leave it undefined, but we also cannot define it yet. So this gives us a placeholder for the hook to standardized data.

Best,

-Arle
Received on Tuesday, 10 July 2012 14:23:33 UTC

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