Schematron constraint for ab is too crude

[martindholmes]

Line 52 of ab.xml has this Schematron constraint:

<constraintSpec ident="abstractModel-structure-l" scheme="schematron">
    <constraint>
      <report xmlns="http://purl.oclc.org/dsdl/schematron" xmlns:tei="http://www.tei-c.org/ns/1.0" test="ancestor::tei:l or ancestor::tei:lg">
        Abstract model violation: Lines may not contain higher-level divisions such as p or ab.
      </report>
    </constraint>
  </constraintSpec>

However, the content models for <lg> and <l> both allow a child <figure>, and <figure> quite reasonably allows child <ab> and child <p>. So I think the constraint might be modified to allow for this:

<constraintSpec ident="abstractModel-structure-l" scheme="schematron">
    <constraint>
      <report xmlns="http://purl.oclc.org/dsdl/schematron" xmlns:tei="http://www.tei-c.org/ns/1.0" test="(ancestor::tei:l or ancestor::tei:lg) and not(parent::figure)">
        Abstract model violation: Lines may not contain higher-level divisions such as p or ab.
      </report>
    </constraint>
  </constraintSpec>

There is a similar but already slightly-qualified constraint in p.xml that would also have to be modified.

[lb42]

But should <l> be allowed to contain <figure> ? I am finding it hard to imagine a real life case where this would make sense (I can -- just about -- see a case for <lg> though it's stretching things)

[jamescummings]

@lb42 I was going to say "what about a poem constructed from images?" But then predict you'd say "Those are graphics not figures." And I'd say "Oh, yeah." So thought I'd shortcut the conversation in case anyone else was going to suggest that. ;-)

[lb42]

@jamescummings you know me too well.

[PFSchaffner]

Rebus poetry is of course common. Many rebus images contain text (some consist entirely of text). Question is whether that text can or should be captured in the desc element within graphic, or whether as transcriptional they should be captured in some text-bearing element within figure. ... I'm sure there are also some odd-ball outlier pieces of verse that incorporate an unspeakable illustration of some kind within them. "Look at this (figure) / what do you see? / I see a (figure) / looking back at me." Or something equally horrible. Once you've seen ledgers (tables) and captioned illustrations within sp, you'll not rule out anything.

[lb42]

Yes, but as previously noted, I would suggest that if something is a poem, it should be encoded as such using <l> elements, and if parts of a line are represented graphically, rather than textually, the element <graphic> is available. See attached example of a well known case.

[PFSchaffner]

Yeah, I know: I was positing the case in which the graphic elements themselves contain text too.

[PFSchaffner]

[ebeshero]

Hmm. @PFSchaffner ‘s example presents graphically a nice case of when we’d want a <figure> in the line, doesn’t it?

[PFSchaffner]

Contrived, I admit, but yes, that was the point. ... and pretty good for something done while fumbling through breakfast.

[ebeshero]

Call it “born digital poetry” then! :-)

[ebeshero]

I don’t know, @jamescummings and @lb42. Looking at our examples in the Guidelines for <graphic>, we seem pretty committed to wrapping it in a <figure> anyway for holding associated metadata. I think we are just fine with <figure> and we definitely should not disallow it. But should we be permitting <graphic> by itself? I am not so sure of that.

https://tei-c.org/release/doc/tei-p5-doc/en/html/examples-graphic.html

[ebeshero]

What I am noticing in the examples is the contraption of <figdesc> with <graphic> inside <figure>, which conveniently associates text and image. What other ways do we have to make such associations?

This reminds me of the best practice urged by the w3c for HTML in providing text descriptors of images—a bit of text metadata would be expected to support screen readers. Perhaps for images that function semantically in a line of verse, we would expect some descriptor? This isn’t the same case as using <graphic> to accompany a transcription of a page surface.

[martindholmes]

@lb42 Here's an example of a <figure> in the middle of an <lg>:

https://hcmc.uvic.ca/~vicpoems/page_images/goodwords/11/goodwords_11_465_areverieandasong.jpg

This is very common, and if a line were to wrap in a particular way, it's easy to imagine a case where it could appear within <l> as well. I don't have examples to hand of this, because of course our encoders can't (yet) encode any of these figures in the right places because they have descendant elements which are not allowed due to the Schematron rule.