Menu
▾
▴
#368 Better facilities for controlling attribute classes
closed-wont-fix
nobody
5
2013-01-08
2012-06-28
No
1. The "change classes" tab has no way of saying "suppress this class" analogous to the "exclude/include" radio buttons on the list of elements in a module. You can delete individual attributes from a class, one by one, but you can't remove the class itself
2. There is no "back" button from the "list of attributes" screen for a class, analogous to the back button on the list of elements screen : you have to use the browser's back button -- twice, for some reason -- to get back to the list of classes
3. The list of attributes screen does not tell you which module has provided the class you are modifying
A consequence of (3) above is that if you modify a module-specific class (e.g. to delete it), then all the elements defined by that module are included in your schema, without your knowing!
I think0 requests 1 and 3 come under the heading of "Roma is a not a general-purpose ODD editor", unfortunately. Request 2 seems like a corrigible error, though, at first sight.
I have set the "Assigned" back to "None" for this ticket, sorry. I will definitely not be able to do any work on Roma in the foreseeable future. Of course, very happy if someone else picks up the code.
with regard to "if you modify a module-specific class
(e.g. to delete it), then all the elements defined by that module are
included in your schema, without your knowing! ", is this a function of the Roma interface, or the ODD processor. ie is the generated ODD what you expect?
The problem is that you see a list of all classes with no indication of which module instantiates them. If you decide you don't want e.g. att.coordinated, you can delete it. But in order to do that, the ODD generated by roma has to include the module "transcr" as well whether or not you included it explicitly in the list of modules in your ODD: roma does this by adding <moduleRef key="transcr" except=""/> to your ODD. Consequently all of its elements appear in your schema which can be quite a surprise. So the answer to your last question is "a bit of both really".... Since class changes often affect elements not included in the module where those classes are not defined, I don't think an ODD processor should take a reference to a class in module x as a licence to load all the definitions for module x as well. (Roma presumably has no choice in this respect though, cos it does everything by exclusion. But then surely it ought to exclude all the elements in module x if it hasn't been requested as well)
Ah, I see what you mean. This could be ameliorated by
adding another column of "module" to http://www.tei-c.org/Roma/startroma.php?mode=changeClasses, I think?
not that hard to do, if you can find a motivated programmer to dive
in and alter the XSLT which generates that, and the XQuery it reads
until/unless someone works on Roma again, there is no chance of fixing this. i am unassigning myself from this again
Closing ticket until such time as Roma development or Rewrite is undertaken.