Re: [ISSUE 34] Quality error category proposal

Hi Phil, all,

I understand your reaction - the issue is just that we don't know what
values to put into errorType, errorSeverity, errorScore. If each tool
(producer or consumer) has different values, we won't achieve
interoperability. The reason why I brought up this external reference
proposal was that it gives us time - time to decide later on this. But I
understand your need for inline markup, too.

Felix

2012/7/10 Phil Ritchie <philr@vistatec.ie>

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



-- 
Felix Sasaki
DFKI / W3C Fellow