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

[raffazizzi]

<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

Original comment by: sebastianrahtz

[raffazizzi]

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

Original comment by: sebastianrahtz

[raffazizzi]

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.

Original comment by: lb42

[raffazizzi]

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?

Original comment by: kshawkin

[raffazizzi]

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

Original comment by: martindholmes

[raffazizzi]

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.

Original comment by: sebastianrahtz

[raffazizzi]

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.

Original comment by: jamescummings

[raffazizzi]

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

Original comment by: martindholmes

[raffazizzi]

• status: open --> open-accepted
• milestone: --> GREEN

Original comment by: lb42

[raffazizzi]

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.

Original comment by: lb42

[raffazizzi]

• status: open-accepted --> open

Original comment by: sebastianrahtz

[raffazizzi]

• status: open --> closed-fixed

Original comment by: sebastianrahtz