> When I come to the appDetail tag, it gets a bit harder. I want to
> specify co-occurrence constraints, such that:
> -When adType="appURI", then content can only be a well-formed URI.
> -When adType="lastSave", then content can only be a date tag.
> -When adType="sectionsTouched", then content can only be a list of valid
> pointers to elements in the document.
> -When adType is anything else, any text is allowed.
As Sebastian says, content constraints are not so easily supported by
the current ODD system, though the schematron approach is certainly
I think we're caught here between the need to make something simple and
generalisable, and something specific to a particular application. In
general, TEI favours the former, of course. And in this case, since the
appDetails are by definition for use of the application, surely their
validation ought to be left to the application? After all, even if you
could check that both are dates, I'll bet your application might want to
check that the date in an appDetail of type "lastUpdate" is later than
one in an appDetail of type "created".
On the other hand, it's plausible to argue that appDetails will always
involve data of some fairly obvious types: so you might say that appInfo
should contain a mixture of (say) appDate, appURI, and appDetail
children. But the kosher TEI approach would be to say that appDetail can
contain any member of the model.appDetailPart class, irrespective of its
adType, alternated with text (and make ptr, ptrGroup, date, etc. members
of that class). And leave the validation to the application. As I see
it, the point of this facility is to permit any application to place its
own data there, for its own use. So TEI shouldn't try to legislate
either for the names of bits of data, nor the constraints associated
with those names. Your app wants to call it "lastUpdate", but mine wants
to call it "updated". I don't think deciding such matters is within
scope for the TEI.