Annex B (informative) provides convenience links to the executable OCL files that implement the EMOF and CMOF constraints (with respect to the shared metamodel for MOF Core and UML). The provided links are crossed:
The constraints for EMOF are in: http://www.omg.org/spec/MOF/20131001/CMOFConstraints.ocl The constraints for CMOF are in: http://www,omg.org.spec/MOF/20131001/EMOFConstraints.ocl

Also, the second link has a comma instead of a period between www and omg.

The diagram on p6 includes URIStore but with incomplete lines.

There is no subsection for it in 6.2.

Summary:
At MOF 1.4, packages can be related through:

• import
• nesting
• inheritance
• clustering
  We haven't really addressed this aspect of migration which should be added to Chapter 9.
  Personally I think there's little value in MOF 1.4 nesting and inheritance relationships and they're infrequently used in real metamodels (if people know what they're doing - occasionally people nest packages in UML Profile for MOF without realizing the implications).

In UML2 though we do still have a nesting relationship between packages so should consider the implications in terms of MOF constraints and extents.

Conversely we no longer have clustering (the most useful relationship in MOF 1.4) though we do have merging (with 2 flavors): we need to consider the runtime implications of instantiating a package that merges other packages. Is it the same as clustering?

Summary:
isID semantics - the 'may be used' is too weak. I think myself and Joaquin have made the point that we
need to specify the URI structure to get interoperability (and I don't mean the W3C standard - I mean how to construct
the URI from the objects/extents/properties/containers being identified).

The overview diagram in section 6.2 shows an operation:

Facility::getWorkspace(id : String[0..1]) : Workspace

However, section 6.2.1.3 describes an operation with a different signature:

Facility::getWorkspace(id : String[0..1]) : Workspace[0..*]

Which is it?

2. Section 7 should be applied to the other specifications not left in this specification

1. The figures should have numbers and captions

The figure in section 6.2 shows a URIStore class with two broken lines (associations? Generalizations? Something else?)
There is no entry for URIStore in the spec but there is a reference to it in 6.2.1.3:

Facility::createStore(name : String, contextURI : String[0..1], ….)

The description of the contextURI parameter says:

The URI to be used to address this Store. If specified, an instance of URIStore will be created.

So, is there a URIStore metaclass in MOF FOL or not?

MOF Facility Object Lifecycle (FOL) 2.0: 6.4.2 Session does not appear in any diagram