I have tested a reused attribute destinationType that also has enum values. The XSD puts the documentation before the type. I have tested with an example Frank configuration that the documentation is visible in VSCode.
For attributes in a declared group or cumulative group, the decision whether they are inline or referenced cannot be taken on creation time.
There is a new class AttributeReuseManager. When a declared or cumulative group needs an attribute, a task is created in the AttributeReuseManager.
When all attribute creation tasks are in, the AttributeReuseManager decides which attributes are inline and which are references. Then a callback is accessed to create the attributes. These callbacks are implemented in DocWriterNew, the class that writes the XSDs.
There are also attributes that do not come from the model, like active and elementRole. Such attributes are also handled via the AttributeReuseManager, because the sequence of all attributes should not be influenced by using the AttributeReuseManager. AttributeReuseManager knows about all attributes and maintains them in the right order.
When an attribute is mandatory, the clause use=required should appear in the reference, not the referee. Otherwise the XSDs are invalid.
When an attribute's value is restricted by an enum, the attribute documentation should come before the type definition.
I have tested a reused attribute
destinationType
that also has enum values. The XSD puts the documentation before the type. I have tested with an example Frank configuration that the documentation is visible in VSCode.