I have some minor remarks on the rewrite:

Thank you, Martina!

#DEFCON

1) ":" is missing before the enumeration of the three distinctly different ways of specifying a content model. Do you want to use <list rend="bulleted"> for that?

The enumeration of the three distinctly different ways of specifying a content model were encoded just as paragraphs, not a list. I'll try a list so we can take a look at it that way, too. Take a look at https://bauman.zapto.org/~syd/temp/4TEICouncil/TD_DEFCON.html and let me know what you think.

#DEFCONTEI

2) ...

Deferred for now.

3) for consistency reasons I'd delete the "an" in the specification of <alternate>

I think both the <desc> for <sequence> and the <desc> for <alternate> are pretty lame. How about: <sequence>: indicates that the constructs referenced by its children form a sequence <alternate>: indicates that the constructs referenced by its children form an alternation

4) explanation of the second example: is it worth to mention the difference in using the cardinality on <elementRef> or <alternate>?

I don't think it can hurt, but I was sort of thinking (at the time) that even what I have is overkill, as this is covered in the Gentle Introduction to XML (at #SG146).

5) I wonder if there should be a simple example on using <sequence>? 8) should there be an example using <classRef> OR <macroRef> too?

Same as above -- how much do we explain the use of content models here, as opposed to just the syntax of PureODD (leaving the explanation of how to use content models to SG)?

7) the <anyElement> is not mentioned in the section (resp. the whole chapter) any more.

Oh dear. I'm not sure what "resp." means, but you're right, the only place that <anyElement> is mentioned in the entire _Guidelines_ (besides its own tagdoc) is in the remakrs of elementSpec/@defaultExceptions! I will try to write something up shortly, but Lou is really much better at this than I.

9) @bibliography on the left: that's only on the paderborn jenkins, see: ...

Whew!

I went through that a while ago. It's straightforward to turn it off. When they suddenly introduced it without warning, it caused us all sorts of problems because we use Jenkins builds to proof all our sites. On 2018-01-22 07:58 AM, Peter Stadler wrote:

...

Am 22.01.2018 um 15:07 schrieb Syd Bauman :

...

9) @bibliography on the left: that's only on the paderborn jenkins, see: ...

Whew! Yes, that’s a security constraint. Jenkins per default now prohibits execution of javascript etc. per Content-Security-Policy (https://content-security-policy.com/). Just learned about this and now need to investigate how to relax those restrictions …

Best Peter