ODD processing always has a surprise up its virtual sleeve. Let's
suppose your ODD wants to add <persName> and <orgName> and <placeName>
from the namesdates module. Let's further suppose you want to see only
W3C date values in your dating attributes.
So your ODD has something like this
<moduleRef key="namesdates" include="orgName persName placeName"/>
<classSpec type="atts" ident="att.datable-iso" mode="delete"
module="namesdates"/>
<classSpec type="atts" ident="att.datable-custom" mode="delete"
module="namesdates"/>
Sound plausible? But it doesn't do what you expect.
In the first place, the presence of the module attribute on <classSpec>
generates the following entirely mysterious schematron error :
E [ISO Schematron] Specification att.datable-custom: the value of the
module attribute ("namesdates") should correspond to an existing module,
via a moduleSpec or moduleRef
In the second place, the moduleRef to namesdates will naturally include
those classes along with the elements you've requested.
In the third place, if you realise this is happening (and you are a
smart ODD coookie if you do), you can replace the moduleref with
elementRefs for the elements you want
<elementRef key=orgName/>
<elementRef key="persName"/>
<elementRef key="placeName"/>
Whereupon, huzza, those pesky classes disappear. Not because of your
<classSpec>s of course, but because you've removed the moduleRef`
In fact you can remove the classSpecs completely: if there is any way to
delete a class which is specific to a module (i.e. not defined in the
tei module), this isn't it, though it works fine for classes which *are*
defined in that module.