Hello,
I think Hugh is right in saying that this is a bug. All examples on the
guidelines have no text content within <app> and examples of more verbose
apparatus entries are encoded using <note>, for example: "The note element
may also be used to record the specific wording of notes in the apparatus
of the source edition, as here in a transcription of Friedrich Klaeber's
note on Beowulf 2207a:" (towards the end of 12.1.1
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPEN)
So I'm not sure the ship has really sailed. Also we've introduced important
changes to <rdg> in this release already, so this fix seems small and
adequate.
Raff
On Tue, Oct 13, 2015 at 9:16 AM, James Cummings
While I wish app's content model had always been the data-like construct that Hugh imagines, I think I'm with Lou in thinking that said ship has sailed.
I'd vote for implementing #2 and seeing what breaks then. (before releasing). ;-)
-James
On 13/10/15 14:09, Hugh Cayless wrote:
That would be a convincing argument if <app> were in any way suitable for encoding printed apparatus. I thought we’d decided that <note type="app"> was the solution for that? I’m pretty convinced <app> was never intended for that purpose and is unsuited for it, even with the current, messed-up content model. I can be persuaded that longstanding brokenness is just something we have to live with though.
Solution #2 would be either to directly permit <app> where it can occur now, or to create a new model class for it and include that. It’s not hard, just sort of verbose. If people are convinced that tightening up <app>’s content model is unwise, I’ll do #2.
On Oct 13, 2015, at 8:43 , Lou Burnard
wrote:
The trouble with your first solution is that it's likely to break things quite badly for people using <app> to record an existing apparatus from a printed source, for whom the availability of model.global elements like <pb/> or <lb/> or even <gap/> within <app> is actually quite reasonable and not "nuts" at all. You might prefer it if <app> became a purely data-only construct, but that's really quite a shift from its current model. So I don't think coming up with such a radically different content model for it counts as a simple bug fix. The argument "should never have been allowed in the first place" is a very dangerous one.
How would your solution (2) work exactly?
On 13/10/15 13:20, Hugh Cayless wrote:
I think we’re going to have to do a point release. Most of the Stylesheets errors are fixable just by regenerating the expected results, but the tests revealed a bug via Odd by Example, which won’t produce a valid XSD content model for <app>. The short version is, that by adding <app> to model.global.edit, <app>’s own rather messed up content model causes an invalid XSD to be generated (it permits model.global inside it). There are two possible fixes for this:
1) Fix <app>’s content model, which I think is actually seriously incorrect. It should be more like the content model of <choice>, since <app> contains either alternates (<lem>, <rdg>s, and <rdgGrp>s) or notes (<note>, <wit>, <witDetail>). It shouldn’t directly contain a <gap>, for example. That’s actually more than a little nuts.
2) Add a model.appLike (or similar) and allow it almost anywhere.
I’d prefer #1, because it fixes what I see as a bug. This would invalidate content like <app><lem>foo</lem><gap/><rdg>bar></rdg></app>, but I would argue very strongly that this should never have been allowed in the first place, and I can’t see how it would make any sense. I’d be astonished if anyone was actually doing this in the wild.
I also think this should have showed up way earlier, and the reason it didn’t is that the Stylesheets tests are pegged by default to the current release, so Jenkins is not checking them against the contents of the master branch. I do see the value of having them test against the current release in terms of pure Stylesheets development, but it’s a serious flaw for any work that should happen in tandem. I’d like to suggest that we add a second build of the Stylesheets in Jenkins that runs its tests against the last build of TEIP5. That would a) alert us immediately if tests need to be regenerated, and b) flag things like this Odd By Example bug early on.
Thoughts? I can implement either fix fairly quickly. And then do a 2.9.1 release.
Hugh
-- 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
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
-- 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