Summary: an ODD customization file needs to be able to say "I am a customization of that customization" as opposed to a customization of the whole TEI.
Currently a TEI customization is written as an ODD file that works by loading modules and obtaining information about TEI classes, etc., from a copy of the TEI source. The set of specifications from the specified modules in the TEI source are established, and requests to add, delete, replace, or change elements, classes, etc. are made against that set of specifications.
E.g., by default the commandline roma.sh uses the sources obtainable through http://tei.oucs.ox.ac.uk/Query/ (to find out which actual version of the TEI sources that server is using, see http://tei.oucs.ox.ac.uk/Query/getversion.xq\). This can be over-ridden to use any other TEI XQuery server with the --teiserver switch, or to use a local copy of the source files using the --localsource switch.
Thus we say that a customization is "built against" the TEI source. But in order for ODD to properly represent the delta from one encoding scheme to another, and thus gain the advantages of so doing, an ODD customization must be able to be built against another ODD customization, rather than against the TEI sources.
A limited version of this can already be accomplished. One can specify as the local source using the --localsource switch the "compiled ODD" file that was created by a previous execution of roma.sh that had the --compile or --debug switch specified. But this is unsatisfactory for several reasons:
1) It is not descriptive, has no abstraction
2) An ODD itself does not formally indicate against which it should be built
3) Customized attribute classes cannot be customized (as they are no longer first-class objects in the compiled ODD)
4) The compiled ODD must reside on the local machine
5) This is very hard for ordinary users to accomplish (although a front-end might alleviate that)
So I suggest TEI needs a mechanism for a <schemaSpec> to specify that against which it should be built. This should likely take the form of an attribute to <schemaSpec>, perhaps customizationOf=, which points (probably via URI, but perhaps by co-reference?) to an ODD customization file. If this optional attribute were not specified, the default would be to build against the usual TEI source, of course.