In my own copy of the Guidelines, which I’ll probably switch to a branch in the main repo soon, I’ve been playing with the new app. crit. capabilities. As you probably remember, we decided that allowing larger structures inside <lem> and <rdg> made sense, as long as there wasn’t any violation of the abstract model (e.g. using <rdg> to put a <p> inside a <p>). I’ve been experimenting with adding Schematron rules that enforce abstract model concepts, such as: "no <p> inside <p> or <ab>", "no <div> inside <p>" etc. These are general rules, nothing to do with the critical apparatus changes per se, but they should help. The commit with the changes is https://github.com/hcayless/TEI-Guidelines/commit/66d11fab1be737c0f17ad4521b... https://github.com/hcayless/TEI-Guidelines/commit/66d11fab1be737c0f17ad4521b... and you can experiment by grabbing a copy of https://github.com/hcayless/TEI-Guidelines/blob/appcrit/AppCrit/examples/Pro... https://github.com/hcayless/TEI-Guidelines/blob/appcrit/AppCrit/examples/Pro... and trying to cheat by putting, say, <p> inside a <rdg> inside an <l>. If you do this in Oxygen, it should fuss at you and identify the problem at the correct spot. There are changes to prose that still need to be made, and there are probably more Schematron rules we could add, but I think this is workable. Thoughts?
While I thank you for the work on the action, I think that you've hit the crux of the problem for the "just do it in Schematron" scenario: how do we maintain the list of elements not allowed inside certain elements, and how do we maintain the list of elements not allowed to contain certain other elements? The first major hurdle is where do we draw the line as to what is permitted inside <lem> & <rdg>, presuming proper ancestry? Is <p> allowed? (Certainly, it's the original request, right?) Then of course <ab> must be allowed, it's in the same class. And <l> is at the same logical level, so it must be too. So, too, with <head>, <signature>, <byline>, etc. I'm sure it will be argued that <div> should be allowed (think witness B has a section or chapter witness A does not have); <lg> is at the same logical level, so it should be allowed, too. How about <front>, <body>, and <back>? So (in my mind) the content model of <rdg> has to allow at least * model.gLike * model.phrase * model.inter * model.global * model.rdgPart * model.pLike * model.lLike * model.divTop * model.divBottom * lg * sp * spGrp Now, as I intimated above, we have to work out which ones are not allowed as descendants of which others. I think the right way to do this is by class, not individual element, and then to generate the actual Schematron rules required at build time. The advantage is that when a new element is added to, say, model.divTop (by either TEI Council or a customizer) it gets added to the correct rule automatically. The disadvantage is it may be quite hard to do. There is an action on me from the June conference call to investigate such a scenario. And indeed I did start work on it, but IIRC I ran into a wall pretty quickly, and never got back to it. Thanks for the push, then, Hugh. If we take a look at the above list, the questions for the group are, in my mind 1) is it complete? 2) are there things that should be removed from it? 3) which tings on it are not permitted as descendants of which other things?
In my own copy of the Guidelines, which I’ll probably switch to a branch in the main repo soon, I’ve been playing with the new app. crit. capabilities. As you probably remember, we decided that allowing larger structures inside <lem> and <rdg> made sense, as long as there wasn’t any violation of the abstract model (e.g. using <rdg> to put a <p> inside a <p>). I’ve been experimenting with adding Schematron rules that enforce abstract model concepts, such as: "no <p> inside <p> or <ab>", "no <div> inside <p>" etc. These are general rules, nothing to do with the critical apparatus changes per se, but they should help. The commit with the changes is https://github.com/hcayless/TEI-Guidelines/commit/66d11fab1be737c0f17ad4521b... https://github.com/hcayless/TEI-Guidelines/commit/66d11fab1be737c0f17ad4521b... and you can experiment by grabbing a copy of https://github.com/hcayless/TEI-Guidelines/blob/appcrit/AppCrit/examples/Pro... https://github.com/hcayless/TEI-Guidelines/blob/appcrit/AppCrit/examples/Pro... and trying to cheat by putting, say, <p> inside a <rdg> inside an <l>. If you do this in Oxygen, it should fuss at you and identify the problem at the correct spot.
There are changes to prose that still need to be made, and there are probably more Schematron rules we could add, but I think this is workable. Thoughts?
participants (2)
-
Hugh Cayless -
Syd Bauman