Menu
▾
▴
#490 un-bundle @cert and @resp
I want to suggest that @cert doesn't belong in att.responsibility. In implementing FR 465 I was originally going to add @source to att.responsibility and remove att.source. But there are elements that use att.source (like egXML) for which @cert makes no sense at all. In the end I made att.responsibility a member of att.source, but I think it would be better to divorce @cert from @resp and perhaps still combine @source and @resp into one class. I can see @resp being useful anywhere @source is (with the possible exceptions of q and quote) but @cert is only going to apply to things which are (on some level) guesses. Arguments against? For?
+1 from me on this. It will help in making @resp more generally available, per FR 443:
https://sourceforge.net/p/tei/feature-requests/443/
Hrmmm. I suppose I can imagine using @cert on egXML where I was transcribing a textbook with code samples. If @cert is "signifies the degree of certainty associated with the intervention or interpretation." then I guess on egXML I might think it means how certain I am that it is an example of the xml phenomena under discussion. I certainly have never used it in this way though. [Devil's Advocate argument really.]
I presume you are suggesting att.certainty or something as a new class to hold @cert? Only backwards-compatibility issues are where people have done something specific with @cert as a member of att.responsibility... but trivial to change.
Assigning to Peter Stadler to triage and report to council, etc.
Assigning to Martin Holmes to be resolved by the "Global Applicability of att.responsibility" task force as decided during Council Oxford meeting 2014-07-01
Closed as Council decided this morning to keep @cert and @resp bundled and to make them global per [FR 443]