#306 Allow Block Elements inside abstract

[Thomas Schraitle]

Problem

In the DocBook mailinglist I've suggested to extend the content model for abstract.

Currently, abstract is definied in DocBook 5.0 as follows:

db.abstract =    
## A summary
element abstract {
  db.abstract.attlist, db.abstract.info, db.para.blocks+
}

Adding block elements as a child of abstract is not possible. As a writer, you are forced to insert your block elements into para. This makes it difficult to create a customization of DocBook whereas para behaves like simpara.

If abstract was designed to contain text only, why allow para in addition? Allowing block elements therein makes it a bit easier for writers.

Solution

As such, I would propose to allow also block elements as a child of abstract:

db.abstract =    
## A summary
element abstract {
  db.abstract.attlist, db.abstract.info, (db.para.blocks | db.nopara.blocks)+
}

or even all block elements, as an alternative:

db.abstract =    
## A summary
element abstract {
  db.abstract.attlist, db.abstract.info, db.all.blocks+
}

Benefits

I see the following benefits:

• The above change is backward compatible; it doesn't introduce any structural change (except as it allows block elements now).
• Any existing DocBook 5 documents are still valid.
• As DocBook had always a great degree of freedom, IMHO it shouldn't force the user to insert block elements inside paras. Allowing such block elements as child elements just makes it feel more "natural" :)
• Some styleguides require a list to illustrate the main points of a chapter. This would mean to use list elements inside paras. Allowing block elements in abstract makes DocBook schema customization easier.

(I was unsure which milestone to select, leaving it as 5.1 for the time being).

[Thomas Schraitle]

I see, db.nonpara.blocks contains db.bridgehead. Not sure if this would be useful. Better we should disallow it inside an abstract.