You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: