#430 give <eg> a proper content model or make it like <pre>

GREEN
closed-fixed
nobody
5
2013-04-13
2013-01-29
Sebastian Rahtz
No

<eg> is long in the tooth. It was used in the past, it seems, as a synonym for HTML <pre>, ie preformatted code content, but its documentation does not reflect that, and its use in the Guidelines is now fairly limited. Because its content model is just 'text', it cannot be used to eg show highlighted bits of code,
or show non-unicode characters. I suggest that either
- it be regarded as a sibling of <quote> and be given a macro.phraseSeq content model (vel. sim)
or
-it be documented as different from other TEI elements in that a value of xml:space="preserve" is assumed, allowing true <pre>-like behaviour

Discussion

  • by the way, all multiline uses of <eg> in the Guidelines have xml:space="preserve" added

     
  • Lou Burnard
    Lou Burnard
    2013-02-06

    It's not used much in the Guidelines because we don't often exemplify anything that isn't XML (for which we have egXML) but it has a place in the sun, surely, as a means of marking up "illustrative examples" -- not quite the same thing as <quote>, I think. I agree that its content model should include e.g. <lb/> (in which case the @xml:space issue either goes away or becomes more fraught) and <hi> but probably not e.g. <choice> or any of the other editorial components of macro.phraseSeq.

    You'll probably want to revise its current <remarks> somewhat too. With an axe.

    I think you may have invented the desired mapping to <pre> -- it's nowehere stated as such in the prose as far as I can see.

     
  • Kevin Hawkins
    Kevin Hawkins
    2013-02-06

    I agree with Lou about the use case, and I think there are use cases in which whitespace is not significant. So while a default value of @xml:space is okay, we should allow more than one value for @xml:space.

    However, I don't know where to draw the line on what content should be allowed in <eg>. What if you're encoding an old textbook and you spot an error in the example that you want to correct?

     
  • Martin Holmes
    Martin Holmes
    2013-02-06

    Don't we need <eg> for examples of e.g. code in non-XML languages?

     
  • Sure, we need <eg> to produce born-digital docs like the Guidelines, no question. My only point is that its not very adequate for the purpose at the moment, so we may as well make it better. Giving it macro.phraseSeq is easiest way to improve it.

    Lou, the comparison with <pre> is nowhere _stated_, but always assumed in processing up until now. every P edition has preserved white space in rendering <eg>, but never said explicitly that this should be done. thats the magic juju I want to exterminate here at least.

     
  • James Cummings
    James Cummings
    2013-02-06

    I'm less certain about what the content model should be. Anything might appear in something that is an illustrative example....no? This isn't just for born digital documents... I might be transcribing an illustrative example and want to mark the persNames in it... or they might have got something wrong in the example and I want to provide the correction or mark the apparent error.

     
  • Martin Holmes
    Martin Holmes
    2013-02-06

    @james: doesn't egXML cover both of your use-cases? Or are you thinking of providing examples of actual broken XML?

     
  • Lou Burnard
    Lou Burnard
    2013-03-30

    • status: open --> open-accepted
    • milestone: --> GREEN
     
  • Lou Burnard
    Lou Burnard
    2013-03-30

    I've made this one green since we seem to be agreed that we need eg and it should have a cointent model of phraseSeq as per (a) above. I am assuming that this means any markup inside an eg element is meant to be interpreted unless it's escaped in the usual way, and likewise that the usual whitespace p[rocessing rules apply.

     
    • status: open-accepted --> open
     
    • status: open --> closed-fixed