[tei-council] module dependency

[Sebastian Rahtz]

There was an action on me to look at this subject.

a) Module "suggestions" are easy. Add a @suggests attribute to moduleSpec,
and the Roma interfaces will assist you in which modules come pre-selected.
They will not, however, stop you deselecting it.  I see no reason not to
implement
this, but it does not gain a lot.

b) Module dependencies are slightly harder. You will not be able
to de-select modules which are marked with @depends (and there will
be a @depends on "core" and  "tei" for all modules), and the command-line
programs will throw an error if you remove the lines. This takes us a
bit farther, at the cost of frustrating (some very few) people who
really do know
what they are doing. I can implement this if the Council decides it is
necessary.

c) Module dependency does not help element-level dependency.
Thus if <msIdentifier> has <settlement> in its content model,
a dependency on namesdates on msdescription cannot guarentee
a result, because <settlement> may have been removed from
namesdates. This can be solved by implementing a full schema check
which sorts out any dangling links (presumably possible to write this,
but I haven't tried).

So my personal conclusion is that b) does not really
buy us anything, since we have no current use for it,
while a) is a simple convenience we might as well put in.
c) _should_ be implemented, but I don't know how
at present.

Views?

-- 
Sebastian Rahtz      

Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

OSS Watch: JISC Open Source Advisory Service
http://www.oss-watch.ac.uk