[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: formal objects in docbook 5
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]