This GitHub repository lets you - our users - log and track issues that you find with our standards and other document. Tag the issue with the standard or standards effected; we will assign it to the relevant group(s) within TC 211.
Throughout the document, figures "UML model for xxx section" are paired with figures "xxx - Dependencies to elements defined in other standards including fully qualified namespaces". However, there is a lack of consistency between these two kind of illustrations.
In almost all of figures, some of the classes defined in the figure "UML model..." appeared in figure "...Dependencies...", too. For example, DataProductSpecification, TermEntry, and AbbreviationEntry are duplicated in Figure 3 and Figure 4.
However, this doesn't match in Figures 14/15; by the same criteria, Figure 15 should also contain DataQuality.
Also, Figure 23 should include the Delivery class.
=======
Above all, to fit the figure title "xxx - Dependencies to elements defined in other standards including fully qualified namespaces", it would be desirable that classes defined in the "UML model..." do not appear in "...Dependencies..." not only because it doesn't make sense, but also because the duplication might break consistency.
Throughout the document, figures "UML model for xxx section" are paired with figures "xxx - Dependencies to elements defined in other standards including fully qualified namespaces". However, there is a lack of consistency between these two kind of illustrations.
In almost all of figures, some of the classes defined in the figure "UML model..." appeared in figure "...Dependencies...", too. For example, DataProductSpecification, TermEntry, and AbbreviationEntry are duplicated in Figure 3 and Figure 4.
However, this doesn't match in Figures 14/15; by the same criteria, Figure 15 should also contain DataQuality.
Also, Figure 23 should include the Delivery class.
======= Above all, to fit the figure title "xxx - Dependencies to elements defined in other standards including fully qualified namespaces", it would be desirable that classes defined in the "UML model..." do not appear in "...Dependencies..." not only because it doesn't make sense, but also because the duplication might break consistency.