Type-able Text Markup for Structured Writing
TypeText -- General Content Model
====
Christian Augustin
2012-01-13 23:14
Experimental
2012-05-06 09:44
~~~~
The general content model of TypeText describes the generic, unspecific structure of TypeText documents - which is quite flexible. Specific content types have more constraints on their structure and will be described on their own.
~~~~
!!!!
== Note ==
The following descriptions of the content model are intentionally semi-formal. It would be nice to use a widely adopted kind of notation/visualization, but I couldn't find one that is not (E)BNF, DTD or XML Schema (which are only of use for those familiar with formal notations).
All I could find was a -> "poll"(http://dev.day.com/ content/ ddc/ blog/ 2007/ 12/ contentmodels.html).
So I'm using an ASCII Art variant I used in the mid 90s for some kind of technical documentation.
If someone can provide some ideas or point to other resources, -> "please contact me"(mailto:mail@typetext.info)!
!!!!
????
I'm unhappy with the current terminology of "document" and "file" (or "page"). The main problem is that both terms are often used as synonyms, and "file" is by now nearly always associated with digital files (documents) as stored on disks etc.
There would be some appropriate terms in German, but they translate to many different English terms that are less clearly distinguished (as far as I can see).
Some terms would be "binder" (this one has so many meanings but sounds good), "folder" (same problem as with "file") and "booklet" (this one could be a candidate, but it sounds "to big"). Others are "page" and "sheet" (but they are tightly associated with a rather small and fixed rectangular space that has restricted content space).
"Folio" could be a candidate: It seems to describe a rather large sheet of paper, suggesting plenty of room for content ...
Using "map" and "section" is too closely related to Structured Writing resp. Information Mapping.
"Topic", though used for topic-based writing and help systems, could be a viable candidate.
With "Topic" there could be a differentiation between "free topics" and "bound topics" which constitute a "binder" (or are part of a binder); this sounds natural to me.
????
-------------------------------------------
Document
A :Document: in TypeText consists of pages (at least one):
Document
+- Pages
-------------------------------------------
Page
A :Page: in TypeText resembles an HTML "page" and is therefor hold by a file.
Page
+- Header
+- Columns Containers, Content Modules,
Tables, Lists,
Content Elements, Annotations
-------------------------------------------
Columns
Columns Container
+- Column
+- ...
Full Container
+- Columns Container, Content Modules,
Tables, Lists,
Content Elements, Annotations
-------------------------------------------
Content Modules
A :Content Module: contains Content Elements or other Content Modules and has therefor this general structure:
Content Module
+- [Columns, Content Modules,]
[Tables, Lists,]
Content Elements, Annotations
Many specific content modules can not contain modules of their own kind or only specific content elements or modules.
-------------------------------------------
Tables
:Tables: can contain Text, Text Elements, Text Markup, Lists, Content Elements and Annotations, but _not_ nested tables. Content Modules are not intended for use in Tables.
Table
+- Caption (optional)
|
+- Table Head
| +- Table Row
| | +- Table Head Cells,
| | Table Data Cells
| +- ... (optional)
|
+- Table Body
| +- Table Row
| | +- Table Head Cells,
| | Table Data Cells
| +- ... (optional)
|
+- Table Foot
+- Table Row
| +- Table Head Cells,
| Table Data Cells
+- ... (optional)
Table Head Cell, Table Data Cell
+- Text, Text Elements, Text Markup,
Paragraphs, Code Examples,
Captions, Lists, Figures
-------------------------------------------
Lists
:Lists: resemble Content Modules but can only contain Text, Text Elements, Text Markup, List Elements and other Lists (nested lists).
Lists should be nested only two levels deep (for easier formatting with layout and text programs like Word, InDesign, FrameMaker and the like).
-------------------------------------------
Content Elements
:Content Elements: can only contain Text (characters), Text Elements and Text Markup.
-------------------------------------------
Text Markup
:Text Markup: can contain Text, Text Elements and Text Markup.
-------------------------------------------
Text Elements
:Text Elements: are special inline elements like images, cross references (a.k.a. "links"), callout numbers, abbreviations, numbers and formulas. They can only contain specific content and Text where appropriate.
!!!!
== Note ==
A TypeText parser may recognize Text Markup in Text portions of Text Elements (e.g. the text of a cross reference), but the result is not generally defined.
!!!!
-------------------------------------------
Text
:Text: contains Characters and Special Characters.
====
Christian Augustin
2012-01-13 23:14
Experimental
2012-05-06 09:44
~~~~
The general content model of TypeText describes the generic, unspecific structure of TypeText documents - which is quite flexible. Specific content types have more constraints on their structure and will be described on their own.
~~~~
!!!!
== Note ==
The following descriptions of the content model are intentionally semi-formal. It would be nice to use a widely adopted kind of notation/visualization, but I couldn't find one that is not (E)BNF, DTD or XML Schema (which are only of use for those familiar with formal notations).
All I could find was a -> "poll"(http://dev.day.com/ content/ ddc/ blog/ 2007/ 12/ contentmodels.html).
So I'm using an ASCII Art variant I used in the mid 90s for some kind of technical documentation.
If someone can provide some ideas or point to other resources, -> "please contact me"(mailto:mail@typetext.info)!
!!!!
????
I'm unhappy with the current terminology of "document" and "file" (or "page"). The main problem is that both terms are often used as synonyms, and "file" is by now nearly always associated with digital files (documents) as stored on disks etc.
There would be some appropriate terms in German, but they translate to many different English terms that are less clearly distinguished (as far as I can see).
Some terms would be "binder" (this one has so many meanings but sounds good), "folder" (same problem as with "file") and "booklet" (this one could be a candidate, but it sounds "to big"). Others are "page" and "sheet" (but they are tightly associated with a rather small and fixed rectangular space that has restricted content space).
"Folio" could be a candidate: It seems to describe a rather large sheet of paper, suggesting plenty of room for content ...
Using "map" and "section" is too closely related to Structured Writing resp. Information Mapping.
"Topic", though used for topic-based writing and help systems, could be a viable candidate.
With "Topic" there could be a differentiation between "free topics" and "bound topics" which constitute a "binder" (or are part of a binder); this sounds natural to me.
????
-------------------------------------------
Document
A :Document: in TypeText consists of pages (at least one):
Document
+- Pages
-------------------------------------------
Page
A :Page: in TypeText resembles an HTML "page" and is therefor hold by a file.
Page
+- Header
+- Columns Containers, Content Modules,
Tables, Lists,
Content Elements, Annotations
-------------------------------------------
Columns
Columns Container
+- Column
+- ...
Full Container
+- Columns Container, Content Modules,
Tables, Lists,
Content Elements, Annotations
-------------------------------------------
Content Modules
A :Content Module: contains Content Elements or other Content Modules and has therefor this general structure:
Content Module
+- [Columns, Content Modules,]
[Tables, Lists,]
Content Elements, Annotations
Many specific content modules can not contain modules of their own kind or only specific content elements or modules.
-------------------------------------------
Tables
:Tables: can contain Text, Text Elements, Text Markup, Lists, Content Elements and Annotations, but _not_ nested tables. Content Modules are not intended for use in Tables.
Table
+- Caption (optional)
|
+- Table Head
| +- Table Row
| | +- Table Head Cells,
| | Table Data Cells
| +- ... (optional)
|
+- Table Body
| +- Table Row
| | +- Table Head Cells,
| | Table Data Cells
| +- ... (optional)
|
+- Table Foot
+- Table Row
| +- Table Head Cells,
| Table Data Cells
+- ... (optional)
Table Head Cell, Table Data Cell
+- Text, Text Elements, Text Markup,
Paragraphs, Code Examples,
Captions, Lists, Figures
-------------------------------------------
Lists
:Lists: resemble Content Modules but can only contain Text, Text Elements, Text Markup, List Elements and other Lists (nested lists).
Lists should be nested only two levels deep (for easier formatting with layout and text programs like Word, InDesign, FrameMaker and the like).
-------------------------------------------
Content Elements
:Content Elements: can only contain Text (characters), Text Elements and Text Markup.
-------------------------------------------
Text Markup
:Text Markup: can contain Text, Text Elements and Text Markup.
-------------------------------------------
Text Elements
:Text Elements: are special inline elements like images, cross references (a.k.a. "links"), callout numbers, abbreviations, numbers and formulas. They can only contain specific content and Text where appropriate.
!!!!
== Note ==
A TypeText parser may recognize Text Markup in Text portions of Text Elements (e.g. the text of a cross reference), but the result is not generally defined.
!!!!
-------------------------------------------
Text
:Text: contains Characters and Special Characters.