formal objects in docbook 5

[Stefan Seefeld <seefeld@sympatico.ca>]

hi there,

docbook uses the term 'formal object' (or short 'formal') in a number
of places to demark some elements. I couldn't find any clear definition
of what it means for an element to be 'formal', other than that it has
a title.

I then ran the first question of 'Some Open Questions' in http://norman.walsh.name/2003/05/21/docbook:

"Is the distinction between formal/informal useful anymore?"

What is the answer to this question in the context of the upcoming
docbook 5 schema ?

The reason I'm asking is that I had come across situations where I would
want a 'list of <A>', where <A> is any domain-specific artifact users
could introduce. The current docbook DTD predefines (hard-codes) a set
of such lists for some 'formal objects' (figures, say), though it is not
clear to me what makes them special. In other words: what taxonomy leads to
figures, equations, images to have the priviledge of being listable ?

Isn't such a property more like an annotation similar to the way indexes
are generated using <indexterm> instead of an intrinsic type (whether it can
be inferred or not) of some elements ?

I'd like to write documents that contain software engineering artifacts
such as 'requirements' or 'use cases'. All I want is the ability to
annotate existing docbook elements (such as variablelist, paragraph,
or even section) to mark them as being a requirement in a way that
allows me to track them, i.e. generate lists of requirements, set up
special links between requirements and 'specifications' with a particular,
domain-specific semantics, etc., etc.

As docbook 5 is now in the making, I figured this is the best time to
bring the topic up. Does the above make any sense at all ? Are there
alternative ways to achieve the same with other (better) techniques ?

Thanks a lot,
		Stefan