A data section is a chunk with ckID "FORM" and this arrangement:

    FORM       ::= "FORM" #{ FormType (LocalChunk | FORM | LIST | CAT)* }
    FormType   ::= ID
    LocalChunk ::= Property | Chunk

The ID "FORM" is a syntactic keyword like "struct" in C.  Think of a
"struct ILBM" containing a field "CMAP".  If you see "FORM" you will know
to expect a FORM type ID (the structure name, "ILBM" in this example) and
a particular contents arrangement or "syntax" (local chunk, FORMs, LISTs,
and CAT ).  A "FORM ILBM", in particular, might contain a local chunk
"CMAP", an "ILBM.CMAP" (to use a qualified name).

So the chunk ID "FORM" indicates a data section.  It implies that the
chunk contains an ID and some number of nested chunks.  In reading a FORM,
like any other chunk, programs must respect its ckSize as a virtual
end-of-file for reading its contents, even if they're truncated.

The FORM type is a restricted ID that may not contain lower case letters
or punctuation characters.  (Cf. Type IDs.  Cf. Single Purpose Files.)

The type-specific information in a FORM is composed of its "local chunks":
data properties and other chunks.  Each FORM type is a local name space
for local chunk IDs.  So "CMAP" local chunks in other FORM types may be
unrelated to "ILBM.CMA"".  More than that, each FORM type defines semantic
scope.  If you know what a FORM ILBM is, you will know what an ILBM.CMAP
is.

Local chunks defined when the FORM type is designed (and therefore known
to all clients of this type) are called "standard" while specialized ones
added later are "nonstandard".

Among the local chunks, property chunks give settings for various details
like text font while the other chunks supply the essential information.
This distinction is not clear cut.  A property setting can be cancelled by
a later setting of the same property.  E.g., in the sequence:

	prop1 = x  (Data A)  prop1 = z  prop1 = y (Data B)

prop1 is = x for Data A, and y for Data B.  The setting prop1 = z has no
effect.

For clarity, the universally reserved chunk IDs "LIST", "FORM", "PROP",
"CAT ", "    ", "LIS1" through "LIS9", "FOR1" through "FOR9", and "CAT1"
through "CAT9" may not be FORM type IDs.

Part 5, below, talks about grouping FORMs into LISTs and CAT s.  They let
you group a bunch of FORMs but don't impose any particular meaning or
constraints on the grouping.  Read on.

[Back to Amiga Developer Docs]