I'm wondering if it's correct that the documentation of the att.media spec [1] doesn't list <media> as a possible member, while in the documentation of the spec of <media> [2], said element IS declared as a member of att.media.</media></media>
I thought that the "Members" bit of the documentation for classes was dynamically derived, in this case from the spec of <media>, and said spec correctly declares the element as a member of att.media.</media>
So I'm wondering if we may be looking at some glitch in the derivation of the documentation?
The same problem is apparent in the current Jenkins build.
I can tell you why this happens, though it may make you unhappy.
<media>subscribes to att.media, but it then overrides that by making @mimeType mandatory. This means it can't simply refer to att.media, but instead copies all the other attributes, alongside the revised @mimeType. So the effect is it gets the right attributes but by copy instead of reference. The generated documentation does not show this clearly at all.There is a requirement, one of these days, to review the documentation generated from ODD and work out better ways of showing what is in the source. As it stands, its lossy. But it is not at all a simple matter to fix, as the process described above is integral to the way the ODD-flattening is done. So I can't offer you any solution at this point, or any likelihood of a fix until someone has the time to do that review of odd2doc.
Would it not help if the obligatoriness of @mimeType on
<media>were forced with Schematron rather than with the copying trick?Please see also ticket [#739], on the odd chance that it might be somehow related.
Related
Bugs:
#739Assigning to Peter for review.
moved to a generic bug description: [bugs:#759]
Last edit: Peter Stadler 2015-05-30