The list of normative references in clause 3 of the AML Beta-1 document is incomplete. In particular a reference to MOF is missing.

Revise References

Some references listed in clause 3 are normative while others are informative only. Further, a normative entry for MOF Core is missing.

Split references into normative and informative subclauses and add MOF to the normative references.

The “QVT” file health/2015-04-05 is actually an HTML file. In fact it is a copy of HTML page from a github site. Unlike the other qvto files which are textual QVT files as I’d expect.

Provided Corrected QVT

The orginal file provided was mislabeled. The correct ALMGlobals.qvto file is provided. This file will replace document Health/2015-04-05. The new document number is Health/2017-05-03

This specification is not related to so should not be dependent on NIEM, merely because an old version of the latter happened to define some useful primitive types

There are no dependency on NIEM. NIEM-UML types were reused

There is no direct dependency on any versions of NIEM in the specification. A link to NIEM-UML version 1 was provided under the normative reference section since NIEM-UML was referenced in section 9.1.1 AML Provisioning Context. The file ReferncesModelProfile.xmi( Health/2015-04-03) reuses several types as defined in http://www.omg.org/spec/NIEM-UML/20120501/XmlPrimitiveTypes.xmi and was identified in the AML Submission Inventory.

The UML XML Primitive Types library represents the data types defined in the XML Schema for Schemas. There is an isomorphic mapping between the types in the UML XML Primitive Type library and the explicitly defined SimpleTypeDefinitions in the Schema for Schemas. This type library is defined by the NIEM-UML Specification. The primary types referenced by AML-UML are the temporal types.

The description of SpecificationDocument.mdzip is not correct. It should list its dependencies

*Resolved in inventory section of the FTF Report *

This issue refers to the inventory document accompanying the adopted submission, it is therefore out of scope for the specification itself. The inventory section of the FTF report will contain the correct description.

This entry in the inventory (health/15-05-02) should instead be a
non-normative section in the specification pointing interested parties at
the AOM Schemas on the OpenEHR site:

Doc Number: Health/2015-05-01
Filename: EclipseFiles.zip
Description: Contains the AOM Schemas for rendering the AOM models in XML
form, and the corresponding eclipse ecore and model generator models.
Normative?: No
URL: http://schemas.openehr.org/v1

Inventory section of FTF report provides correct references

This issue refers to entries in the inventory document accompanying the adopted specification, the issue is therefore out of scope for the specification itself. The inventory section of the FTF Report will contain the correct references with the correct classification.

P94 refers to a MOF metamodel “An AOM Model is an instance of an AOM 2.0 MOF Meta-model. “ but this is not provided as part of the normative files. Even the informative files contain only proprietary ecore metamodel. I believe Eclipse can make use of EMOF which is very close to ecore and is an OMG standard.

Given that the QVT files are normative, there should be normative definitions for the source and target for the transformations

AOM and ADL not under control of OMG

The specifications of the Archetype Object Model (AOM) and Archetype Definition Language (ADL), including their model representations, are issued and owned by the openEHR Foundation, an independent standardization organization. The OMG, and OMG specifications, can only reference AOM and ADL.

The Conformance clause (clause 2) in the AML Beta-1 document has insufficient information. It explains only the relationship between the three profiles, but does not make a statement what has to be implemented by a tool to be in conformance with the AML specification, or a controlled subset if it, if this is intended to be allowed.

A conformant implementation must implement all three profiles

To provide the intended modeling capabilities of AML, all three profiles (AML Reference Model Profile, AML Terminology Binding Profile and AML Constraint Model Profile) are required. Therefore an implementation claiming AML conformance must implement all three conformance points.

The specification document contains a substantial amount of informative background and explanatory material. Since those clauses tend to reference external standards and specifications, like CIME, those clauses must be marked "informative" to state the non-binding nature of the content and references.

Mark clauses informative where applicable

Clause 7 and all its sub-clauses are informative. Mark accordingly