RE: [ISSUE 34] Quality error category proposal

Hi Arle, Phil, all,

> Depends on what the "additional info" means. 
> If you mean the definitions of errors and so forth,
> then no, that would be out of scope for ITS 2.0.

Mmm... I'm not sure a badly-baked cake is better than no cake at all...
If we go the two-levels model I was talking about then I would expect the list of the main types to be part of ITS 2.0, but the sub-category would be outside. That should help.



>>>> type/code of error,
>>> 
>>> This is actually what I see the URL as supplying. Just a code by 
>>> itself does not support interoperability. However, if we point to 
>>> machine-readable information (and define what that information looks 
>> ...
>> The category + sub-category model we talked several times about 
>> may work here as well. Actually it would probably work very well.
>> ...
>
> I think that we'll need something like this. So is your suggestion 
> that the “top level” (issueType in your last examples) be defined 
> in ITS 2.0 as a set of fairly granular categories and issueSubType 
> be left open?

Yes.



> I'm a bit worried still about the idea of a static list of 
> issueType values, but if ITS 2.0 could somehow point to a 
> normative and living database that is updated more frequently 
> than ITS 2.0, it might work. (My worry is that if we embed 
> even these course values in ITS 2.0, the day after it is 
> finalized someone will come along with something we didn't 
> think of and we then have to rev the spec itself over 
> something simple, whereas if we point to an external database,
> then the spec is constant and we simply declare a new 
> value in the database.)

The problem with such 'external' list of values is that there are not linked to the version of ITS. Don't expect most tools to try to get their data in some dynamic way. In addition you have to deal with those data being used as ITS values but outside an ITS process: they may live for a long time in a database or some other form of serialization.

Maybe it could work if we would only *add* to the list and never change the meanings or the names of the values once in the list, but I would still be worried about this.



> Looking at all this, however, I think that the ITS 2.0
> quality model looks like quite the list: its-error; 
> its-errorseverity, its-errorinfo, its-erroragent, 
> its-errorreplacementtext, its-errorname + the ones for 
> declaring the profile.
> ...
> As it's headed, quality will be half of ITS 2.0.

Then probably not many will implement it.



> But let's talk amongst ourselves with Felix when he 
> is back to see what we can come up with. I'm convinced 
> by you and Phil that the "dumb" (single) pointer 
> proposal has its problems, but adding six elemental 
> data categories to handle one task in ITS 2.0 also 
> seems like overkill.

In my opinion the quality-issue --I'll plaid to talk about 'issue' rather than 'error' since those are not necessarily errors-- should be one or possibly two data categories, but no more: a) the very simple inline info and pointer, and b) the issue descriptor referenced by the pointer.

<span its:qaIssue='yes' its:qaNote='the text of the issue' its:qaInfoRef="#more">text</span>

<its:qadescItem id='more'>
 <its:qadescSomething ...>...
<its:qadescItem>

But, sure, let talk tomorrow.

-yves

Received on Wednesday, 18 July 2012 13:13:55 UTC