Hugh -- Are you still working on this? And it's in branch hcayless-appcrit, not branch appcrit, right? (Can we somehow sequester whichever one is *not* current? It's confusing.) I haven't looked through all the rules carefully (but hope to be able to do so tomorrow). But I did notice at least one problem. Everywhere you have not( parent::tei:note ) it should probably be not( ancestor::tei:note ) lest, e.g., the <lg> in the structure <p>This is a dangling paragraph describing superficial sights. <note> <p>An blatant reference to <title>The Dangling Conversation</title>, a Simon and Garfunkel song: <quote> <lg type="verse"> <l>In the dangling conversation</l> <l>And the superficial sighs</l> <l>The borders of our lives</l> </lg> </quote> </p> </note> be flagged by "abstractModel-structure-l" as violating the abstract model. Overall, the current piecemeal approach is problematic, I think. My instinct is we would do better to have all of these <constraint>s in the same place, both in the source (e.g., all in the app.xml file) and in the execution (e.g., all rules have a context of tei:app). So something like the following (which is without thinking things through or testing them :-) <sch:rule context="tei:app"> <sch:report test=" ( ancestor::tei:p[not( ancestor::tei:note ) ] or ancestor::tei:ab[not( ancestor::tei:note ) ] ) and ( descendant::tei:p[not( ancestor::tei:note ) ] or descendant::tei:ab[not( ancestor::tei:note ) ] ) ">An 'app' that is inside a 'p' or 'ab' can not have a 'p' or 'ab' inside it</sch:report> </sch:rule> This has the advantage of being *much* easier to maintain (although not as easy as automagically-generated-at-build-time :-), and that we won't have Schematron rules firing for every <p> and <l>, only for <app>s. It has the disadvantage that the user does not get told precisely which <p> or <ab> is the problem. (But then again, with the current approach the user is only told about 1/2 the problem.)