I still don’t fully understand where the problem is.
Your example looks like a simple list of <>Requirement elements, some of which have a related <Class element.
Is the problem that these requirements, in your example, are (nested) child requirements of another requirement? And they all – parent and children – have the same stereotype?
If this is the case, then you really do have a problem: to print the parent <Requirement, it probably needs to print ‘inline’, with a table of other requirements linked to it via a ‘nesting’ relationship – using a Relationship Table. But eaDocX only allows you to print attributes of the ‘nesting’ connector, or the child requirement – not things which relate to the target requirement.
This may be one of those example where, because eaDocX has a finite set of capabilites, you just can’t do what you need using the out-of-the-box function, so you will need to either write a script, or print the data in a differnet way.
If the children have a different stereotype from the parent, then it’s easy – just create different Profiles for the two stereotypes. As it stands, you kind-of want the same stereotype to print in two different ways, depending on whether it’s a parent or a child. And eadocX can’t do that.
There’s an important more general point here. If you choose to generate your documents from EA – using any generator application – then there will always be restrictions on how things can look. You get all the bebefits of generate document, and this is the price.
