- From: Yves Savourel <ysavourel@enlaso.com>
- Date: Wed, 18 Jul 2012 08:21:33 +0200
- To: <public-multilingualweb-lt@w3.org>
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. Cheers, -yves
Received on Wednesday, 18 July 2012 06:21:56 UTC