Re: [tei-council] rules for enforcing abstract model

Here’s the thing though: when I started to work on this, I quickly realized that <app> isn’t a new, unique problem. There are all sorts of ways already to mess with the abstract model and produce really goofy but perfectly valid TEI. So I started to lean away from putting extra rules in <app> that applied only to <app>, because it would only be solving part of the problem, or rather, it would only be avoiding making the problem worse. So, I’m sympathetic to your wish to put all the rules in one place for ease of maintenance, but I don’t think <app> should be that place, as it’s only one avenue for misbehavior. The best solution might be to have an extra file, containing only Abstract Model rules, that could eventually be generated automatically. Which half of the problem is the user not told about now? It seems to me that having the error be flagged at the site of the error is pretty important.

On Sep 30, 2015, at 23:05 , Syd Bauman wrote:

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 :-)

An 'app' that is inside a 'p' or 'ab' can not have a 'p' or 'ab' inside it

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.)