What is it
AKOMA NTOSO 1.0 Schema
Technical Documentation
#5 — Heading and sidenote
| State | Rejected |
|---|---|
| Area | Attributes and Elements |
| Issue type | Errors |
| Severity | Medium |
| Submitted by | Monica Palmirani |
| Submitted on | Mar 10, 2008 |
| Responsible | Fabio Vitali |
I ask to add "heading" and "sidenote" elements in "blockElements" and "containerElements" content model.
In this way we can markup the heading (title) and the sidenote also in the block, container, etc.
This is particular usefull for the not-structured documents (such as ordinance, legal notice, etc.), in other case we are forced to use ACT and hierElements even if there aren't.
- Steps to reproduce:
-
First of all, you do not need to use act: you can and should use doc if it is not an act. doc has an open content model which allows both hierarchical elements as well as container elements as well as.. well mostly everything. This is the structure that must be used non-structured documents as well as badly structured documents (i.e., those that should, but actually don't, follow some specific drafting rules).
Second, I think we need to clearly understand what a hierarchical element is: a hcontainer is a container that has some "special" content at the beginning, which we may call titles, headings, and so on, and that can EITHER nest with other hcontainers, OR directly contain blocks and other containers.
As such, hcontainers are exactly what you are referring to when you need to specify that there are special elements at their very beginning. It does NOT imply that they should nest: for instance, clauses are hcontainers but do not nest.
For this reasons, I believe that an hcontainer is the right element for these cases. If you can't find the named hcontainer of your choice (section, part, paragraph, chapter, title, book, tome, article, clause, subsection, subpart, subparagraph, subchapter, subtitle or subclause) you can always use the generic element hcontainer itself.
I don't believe we should pollute containers and blocks with such concepts.
I understand your point of view that is based on a clean an net pattern modelling, but also the user need to have clear guidelines on how to markup.
Now in DOC we have hcontainer, container, block. So hypothetically we have at least three valid ways to markup the same document: hcontainer, container, block. But in hcontainer it is possible to include TITLE (heading) and SIDENOTE and in the others not.
So an end user that have a legal notice should have a different behavior if he/she encounter a list of bullets with a sidenote (hcontainer) and the same list without a sidenote (container or blocks).
Some rules are needed. But probably you have already a solution.
* A block is the end of the containment structure. Blocks only contain text and inline elements (that have no internal structure and can appear anywhere in between text). They can be distinguished because you would not expect them to contain other blocks or containers, but only text or inline elements.
* A container does not contain text directly, but contains blocks or other containers that may contain other blocks or other containers and so on, until no further containments of containers is necessary and we only have blocks that actually contain text.
Finally there is the distinction between container and hcontainers.
* An hcontainer, as the name implies, is not completely different from a container. It is in fact a subclass of containers. An hcontainer is a container that has some privileged, identifiable elements at the beginning that in some way identify or qualify or label or introduce the rest of the content. These special elements can be numbers, titles, headings, and so on.
If you can recognize such special elements, then you should use such a special container, i.e., an hcontainer. Otherwise keep on using you normal container.
In your example, the bullet list with a sidenote will be contained in a hcontainer, and the same bullet list without a sidenote will be contained in a simple container.