Re: [ISSUE 34] Quality error category proposal

My first reaction is that it's too simplified. To get any real meaningful 
detail on the error it seems one would have to follow the URI. Could we 
not fallback to having at least errorType, errorSeverity, errorScore? They 
could be packed into errorInfo but that's open to all kinds of abuse.

Perhaps errorProfile should be retained even under the new proposal so 
that one could decide whether to bother following the URI. That is, my 
toolset may know how to parse one machine readable profile but not 
another.

Phil.






From:   Arle Lommel <arle.lommel@dfki.de>
To:     Multilingual Web LT Public List 
<public-multilingualweb-lt@w3.org>, 
Date:   10/07/2012 15:23
Subject:        [ISSUE 34] Quality error category proposal



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

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