Re: [ISSUE 34] Quality error category proposal

Hi Arle, Phil, Felix, all,

So, now that's we've established we can work with implementation that use a referenced annotation rather than directly markup the content, we can move forward with the actual data of the quality-error.

Going back to the three attributes Arle/Felix proposed:

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

I see that this is pushing to get a very simple set of information and define more later.

- when is "later": after the summer or for ITS 3.0?

- depending on what additional info is needed the URI pointer attribute may be useless (because we may end up defining just a few more attribute inline), so do we want to define something that we may not need later?

Personally I see three more information: severity, type/code of error, and a flag indicating if the given issue is active or not.


Received on Wednesday, 18 July 2012 06:21:56 UTC