The lattice of the UML model is converted into a tree, all associations being converted to contained elements causing any shared elements to be copied into others.

Need to add revised text that documents the algorithm and regenerate the XSD.
The single XSD becomes multiple due to the refactoring that resulted in the resolution of other issues

We currently attach RecordKeeper to ManagedRecord, but this was established before we discovered the need to manage record disposition through RecordSet. Is there a case wherein records in a RecordSet have different RecordKeeper's?

Delete association between ManagedRecord and RecordKeeper. Establish association between RecordSet and RecordKeeper.
Provide constraint that RecordSet's cannot be merged in less they have identical RecordKeeper history.
Added constraint to RecordSet: “RecordSets cannot be merged unless they have the same RecordKeeper”. This is probably also a constraint on the DispositionInstructions service.
There is an undesirable direction of dependencies. Split the Role subtypes out of the Party package into an RmsRoles package that extends the Party package.

A document can be shared among multiple ManagedRecord's. The sharing is predicated on the immutability of a Document. CaseFilePart's are permitted to be appendable, deleteable, etc... all modifications of the Document. If a Document is shared among these MR's, constraints must be put on the characteristics of the CaseFilePart to assure to assure the integrity of the Document in the context of the vanilla ManagedRecord.

In examining this seemingly "innocuous" issue, it became clear that our model was somewhat "upside-down". To resolve it, the CaseFile package will be eliminated and the concepts merged into ManagedRecord. Essentially a ManagedRecord is a CaseFile with immutable parts.

Need to provide formal description of behavior for operations. Inter-operability will be a far stretch without it (Larry Johnson, 20091204)

Out of Scope
Revised Text:
None

Currently records sharing a Category are placed into a common RecordSet awaiting a "Cutoff" operation based on an event which is often date related.

CaseFileRecord's do not generally "Close" at the same time or in the same period.

Add constraint that the CaseFileRecord's that are in a RecordSet must be closed for that RecordSet to be Cutoff.

Are we missing a Repository Service? How do we handle the path were the record will be managed? (Bill Manago, 20091112)

We don't want to build in the idea of location and repository structure any more than is necessary. Specifying locations would defeat many of the goals of Cloud Computing, or even basic distributed data principles.
An implementation may gather information on a desired location (whether we recommend doing so or not) by passing it along as a value of an attribute defined in a AttributeProfile
Revised Text: None

RMS would be better cast as a MOF model as opposed to a UML model. Using constructs such as Association Classes cause difficulties in export to XMI and transformation to XSD's. (Raised by Sridhar Iyengar of IBM in the Jacksonville meeting)

We need to have the model remain as a UML model. This is not a metamodel on which models will be based, but is a model itself. The PSM will need to address the issue of Association Class representation in an XSD. That is being worked under Issue 15212
Revised Text: None

CaseFile is referenced in the static structure of the model; however, there are no services defined to capture or modify case files. Has this been further defined or should we assume we develop our own services and interpretation?

The requisite services are to be added

Do we need artificial root element to reach everything in the RMS.XSD

A similar construct was mentioned and used in the Federal Transition Framework XSD. It is not clear for example, that one could transfer ManagedRecords as well as Category for the ManagedRecord to refer to (we may only be able to transfer the Category reference, but not the description of the Category itself

Disposition Note: Merged into 50512
Resolution:
None
Revised Text: Unspecified

We can eliminate this by splitting out the party model (the only reference from ap to rms) into its own namespace

Split out Party and Document from RMSDomain package to eliminate the circularity. Rename packages RmsDomain to RmsCore, Party to RmsParty and Document to RmsDocument.

A number of errors are in the RMS.XSD. Some are namespace problems (there are related issues), others are introduced by the generation of the XSD from the model

Merged into Issue 15212

All services defined underneath “RmsServices” need to have their service operations detailed. They are in the PIM Model, the PSM WSDL model, and in the PSM WSDL artifacts, but not in the PIM service section of the textual specification

Operation definitions have been added

It should be clear that an attribute in the PSM represents a reference to another object and just which object-type it is. For example the attribute might be named a concatenation of the “rolename”, “_”, “ID” to indicate the referenced class via the role of the association. The type of the attribute would be IDREF

Resolved as part of Issue 15212. The convention eventually adopted involved W3C type NCName rather than IDREF.
Revised Text: None

Removing the ports will resolve problems of untyped ports in the XMI.

These two ports were remnants left from services that were eliminated and were therefore untyped. Furthermore, the remaining ports created tool exchange problems. The port diagram is only used for exposition to demonstrate the scope of service provision and consumption, and will be retained in the specification pictorially to provide overview, but they are removed from the XMI. The diagram is updated with one that correctly presents our current suite of services.
Additionally
1. There was a large quantity of Sparx Systems EA extensions in the XMI. These were removed.
2. The original XMI had PSM constructs included that resulted in portability problems. The XMI is now strictly the PIM and now loads cleanly into both MagicDraw and Sparx EA tools.

RecordCreator and RecordKeeper must have Agency, following the same rules/pattern as Provenance designation. The ultimate organization of the RecordCreator and RecordKeeper must be the same.

[JRMS Remaining Issue]

It is agree this Issue is incorrect. It is quite possible for the RecordKeeper to be from an entirely different agency than that indicated by the Provenance of the record (e.g., when records are seized by a law enforcement agency... they become the RecordKeeper for the period of time that they have custody of the record.)
Revised Text: None

On deletion of a record from the RM system what information is kept to track that it existed and has been destroyed and by what authority and perhaps accessioned by NARA or other Transfer.

[JRMS Remaining Issue]

None. However, there may be an additional issue to be raised as to what is deleted when the decision to delete a ManagedRecord is made. The model needs to be notated from ManagedRecord on out with aggregation or containment as to what is contained as part of the record and therefore what will be removed when the ManagedRecord instance is removed.
In terms of what information is retained (as addressed in this issue), that is dependent on the applicable business rules and regulations and therefore is out of scope of this specification.
Revised Text: None.

Package: UseCaseRealizations –Find Disposition Candidates Realization. This package was removed from the submission due to incompleteness & should be added back in and completed.

[JRMS Remaining Issue]

Out of Scope
Revised Text:
None

The specification should have a paragraph that lists all the RMS's mentioined in the UFAC spec, and DoD 5015.2. AS 4390 Australian Records Standard, and all other non-european standards, ahem, not mentioned in the spec.

A paragraph above them, simple and sweet that explains why the OMG RMS specification is compatible with them, listing all these current standards and specifications.

[JRMS Remaining Issue]

Out of Scope
Revised Text:
None

Package: RmsUseCases

[JRMS Remaining Issue]

Out of Scope
Revised Text:
None

According to the Spec, a managed record can have many categories and a category can have many disposition instructions. Therefore, a managed record assigned multiple categories can have multiple dispositions unless a specific user action is taken to assign one disposition plan for the record set that the managed record belongs to. Please explain?

The resolution to the multiple categories is in Section 8.2.4.3 "Category::RecordCategoryAssociation" where the association between ManagedRecord and RecordCategoryAssociation is documented (emphasis added). The multiple RecordCategoryAssociation's are necessary to keep the history via the previous/next association. There is an analogous description for a Category's multiple DispositionInstruction's (only one is current... the remainder are historical)
Revised Text: None