UAF currently claims complying with 42010; but usage of the term “model kind” in DMM is not in line with ISO 42010 (Clause 3.9 model kind = “conventions for a type of modelling”).
In DMM, “Model Kind” refers to a column of the UAF grid, which is more what is called an “Aspect” in the update of the ISO 42010 reference.
Similarly, the rows of the UAF grid, currently called “domain” ―term undefined in UAF― could be called “Perspective”, as it is worked in the update of ISO 42010.

Terms updated to be better compliant with ISO 42010

All appearances of the terms Domain, Viewpoint, and Model Kind renamed in all the documents.

Domain renamed Viewpoint (compliant to ISO 42010)
Viewpoint renamed to View Specification (UAF specific)
ModelKind renamed to Aspect (compliant to ISO 42010)

“A Domain Metamodel (DMM) uses UML Class models to represent individuals, types and tuples that aggregate the concepts defined in DoDAF, MODEM, NAF, DNDAF and other frameworks. “ is not correct… and in fact not possible.

Same terms and concepts provided by the available architecture frameworks are unfortunately not all compatible.
I do recommend either removing this sentence or elaborating on the compatibility of the UAF terms and concepts with those of the other Architecture Framework.
This compatibility definition is a starting point for interoperability between architecting environment and tools.

Text updated

formal/19-11-05 page 11 text revised:
from: A Domain Metamodel (DMM) uses UML Class models to represent individuals, types and tuples that aggregate the concepts defined in DoDAF, MODEM, NAF, DNDAF and other frameworks.
to: A Domain Metamodel (DMM) uses UML Class models to represent individuals, types and tuples that maps the concepts defined in DoDAF, MODEM, NAF, and other frameworks.

Considering the current UAF specification (V1.1beta) available to me, I think that it is not acceptable to do have a part or chapter or at least DMM Clause 4 providing a clear set of definition.
I.e. Key terms are used and not formally defined. In particular, there is no definition for:

• Domain.
• Enterprise
• Architecture
• Model
• Language
• Enterprise Architecture
• Enterprise Model
• Enterprise Model
• Enterprise Modeling Language.

Glossary added into the UAF EA Guide document

Text updated in the UAF DMM document chapter 4 to:
No new terms and definitions have been required to create this specification. All terms are available in the normative references or bibliographic citations for detailed explanation. The modeling concepts specified in this standard e.g., MetaModel Elements, Viewpoints, Aspects, View Specifications, etc. are defined in the appropriate section for that concept. Additional terms are defined in Appendix C: Enterprise Architecture Guide (EAG).

This issue is submitted on behalf of the NATO ACAT group and relates to the handling of effects within the UAF domain meta model.

The ACAT group wishes to extend the concept of achiever by adding StandardOperationalActivity as well as ServiceSpecification as possible achievers in addition to the already available ActualResource.

Duplicates UAF12-48

Duplicates UAF12-48

In v1.1, "systemConcern" was changed to "enterprisePhase". But should have been changed to "EnterprisePhaseConcern" to be more grammatically and technically correct.

FROM
enterprisePhase : ActualEnterprisePhase[*] Relates a Concern to the ActualEnterprisePhase that addresses that
concern (ActualEnterprisePhase is synonym for System in ISO 42010).
TO
enterprisePhaseConcern : ActualEnterprisePhase[*] Relates a Concern to the ActualEnterprisePhase that addresses that
concern (ActualEnterprisePhase is synonym for System in ISO 42010).

No longer relevant

Changes done to the specification as a result of other issues solving makes this issue no longer relevant.
Related changes:
-the addition of the ActualStrategicPhase
-the addition of the Phases relationship between ActualStrategicPhase and Concern.

The constraint that a operationalConnector must be implemented by another connector (resourceConnector) is too strict. I would like to be able to implement a logical connector into physical connectors and part properties. The idea can be seen in Figure 14.8 of A Practical Guide to SysML (second ed).

The connection is possible between two Resource Connectors

The connection is already possible and depicted in the Implements diagram Figure 3:34 – Implements in formal/19-11-07.

SysML allows the use of CallOperationAction as an alternate means of mapping Behaviors (via Operation->Method metaproperty).
UAF 1.1 includes OperationalActivityAction, ProjectActivityAction, ServiceFunctionAction, FunctionAction or SecurityProcessAction which all extend CallBehaviorAction.
UAF 1.1 also includes OperationalMethod, ServiceMethod, ResourceMethod, which extend Operation, and even has metaconstraints requiring appropriately UAF stereotyped Activity used as the Method.

We recommend allowing CallOperationAction to also be stereotyped by the UAF extensions to CallBehaviorAction listed above.
We also recommend creating ProjectMethod and SecurityMethod as extentions to Operation to be consistent with other Domains.
This would facilitate it's use in Operational::Connectivity, Operational::Processes and Security Processes, Project Processes, Personnel Processes, Resource Processes and Resources Connectivity Diagrams and Tables.
This is especially useful to visualize and take advantage of CallOperationAction target pin and method resolution per UML 2.5 13.2.3.5 Behavioral Features and Methods. It is also useful for fUML 1.2.1 Polymorphic Operation Dispatching ability to execute method resolution during simulation and analysis. Thus a tighter integration of UAF with UML method resolution semantics and executability can be achieved both visually and from a simulation and analysis perspective.