Hi I am maybe asking a naive question, but apart from the generic references in chap 23 is there any formal list of Abstract Model constraints that are not Relax Schema enforced constraints? f 2015-10-01 14:26 GMT+02:00 Hugh Cayless <philomousos@gmail.com>:
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 <syd@paramedic.wwp.neu.edu> 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 :-)
<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.)
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- Fabio Ciotti Dipartimento Studi Umanistici, Università di Roma Tor Vergata Presidente Associazione Informatica Umanistica Cultura Digitale