DMN17 — Discrepancy between spec and metamodel for AuthorityRequirement properties

There are three associations in the metamodel for which the properties defined by one end do not appear in the specification. It results in 3 properties for AuthorityRequirement that are not included in Table 22.

For the association BKM2authorityRequirement, the role B end defines bkm: BusinessKnowledgeModel [0..1]
For the association Decision2authorityRequirement, the role B end defines decision: Decision [0..1]
For the association KnowledgeSource2authorityRequirement, the role B end defines knowledgeSource: Knowledge Source [0..1]

If these properties are intentionally excluded from the specification, then I suggest the following changes to the associations:
Name (Role B): remove name
Multiplicity (Role B): set to unspecified
Navigable (Role B): set to false (make it a directional association)

If these properties should be in the spec, I recommend adding them to the table and also making sure the name of the ends are visible in the diagrams for Decision (source for Figure 6-13), BusinessKnowledgeModel (source for Figure 6-15), and KnowledgeSource (source for Figure 6-18).

In fact, as a general comment on all the metamodel diagrams, the role end for the source of a directed relationship (navigable in one direction) should not be named or have any multiplicity, since the target end doesn't "know about" the source end in this kind of relationship. On the other hand, if the association is bidirectional, both ends know about each other, so both ends should be named and the names should be visible on all diagrams in which the association appears. Performing this update will make the alignment between the figures and the text in the spec much better.