Issues for Mailing list of the Records Management Services (RMS) Finalization Task Force 2
To comment on any of these issues, send email to rms-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 14127: Need to finish UseCaseRealizations –Find Disposition Candidates Realization
Issue 14128: Need to finish capturing the relationships between the Use Cases and the actors
Issue 14129: Specification needs declaration of compatibility
Issue 14132: What happens on "destruction" or "transfer"
Issue 14134: RecordCreator and RecordKeeper must have Agency (or the top level organization)
Issue 14971: Are we missing a Repository Service?
Issue 14973: Need to provide formal description of behavior for operations
Issue 14999: Documents shared among CaseFile's and "vanilla" ManagedRecord's
Issue 15000: Relationship of CaseFile "Close" and RecordSet "Cutoff" Operations
Issue 15109: There are Errors in the RMS.XSD
Issue 15110: In the RMS.XSD we have circularity between the rms and ap namespace
Issue 15111: Do we need a root to reach everything in the RMS.XSD
Issue 15114: RecordKeeper is related to ManagedRecord. Shouldn't it be to RecordSet?
Issue 15212: The transformation algorithm from UML to XSD is inadequate for RMS purposes.
Issue 15214: RMS would be better cast as a MOF model as opposed to a UML model
Issue 15228: managed record clarification
Issue 15671: Need convention to name referenced object via IDREF
Issue 15782: Service packages require operation definitions
Issue 15871: RecordKeepers and Suspensions Services no longer exist but their ports are in the specification and the XMI file
Issue 14127: Need to finish UseCaseRealizations –Find Disposition Candidates Realization (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary:
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]
Resolution: Out of Scope
Revised Text:
None
Revised Text:
Actions taken:
July 28, 2009: received issue
April 25, 2011: closed issue
Discussion:
Issue 14128: Need to finish capturing the relationships between the Use Cases and the actors (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: Package: RmsUseCases
[JRMS Remaining Issue]
Resolution: Out of Scope
Revised Text:
None
Revised Text:
Actions taken:
July 28, 2009: received issue
April 25, 2011: closed issue
Discussion:
Issue 14129: Specification needs declaration of compatibility (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: 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]
Resolution: Out of Scope
Revised Text:
None
Revised Text:
Actions taken:
July 28, 2009: received issue
April 25, 2011: closed issue
Discussion:
Issue 14132: What happens on "destruction" or "transfer" (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: 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]
Resolution: 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.
Revised Text:
Actions taken:
July 28, 2009: received issue
April 25, 2011: closed issue
Discussion:
Issue 14134: RecordCreator and RecordKeeper must have Agency (or the top level organization) (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: 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]
Resolution: 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
Revised Text:
Actions taken:
July 28, 2009: received issue
April 25, 2011: closed issue
Discussion:
Issue 14971: Are we missing a Repository Service? (rms-ftf)
Click here for this issue's archive.
Source: Hewlett-Packard (Mr. William Manago, CRM, william.manago(at)autonomy.com.)
Nature: Uncategorized Issue
Severity:
Summary: Are we missing a Repository Service? How do we handle the path were the record will be managed? (Bill Manago, 20091112)
Resolution: 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
Revised Text:
Actions taken:
January 14, 2010: received issue
April 25, 2011: closed issue
Issue 14973: Need to provide formal description of behavior for operations (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: Need to provide formal description of behavior for operations. Inter-operability will be a far stretch without it (Larry Johnson, 20091204)
Resolution: Out of Scope
Revised Text:
None
Revised Text:
Actions taken:
January 14, 2010: received issue
April 25, 2011: closed issue
Discussion:
Issue 14999: Documents shared among CaseFile's and "vanilla" ManagedRecord's (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution: 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.
Revised Text: see dtc/2010-12-08 pages 8 through 35
Actions taken:
January 21, 2010: received issue
April 25, 2011: closed issue
Discussion:
Issue 15000: Relationship of CaseFile "Close" and RecordSet "Cutoff" Operations (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution: Add constraint that the CaseFileRecord's that are in a RecordSet must be closed for that RecordSet to be Cutoff.
Revised Text: Append to first paragraph of the Description of the DispostionActionSpecification diagram AND to the description of Initial Actions in the description of the “Disposition Action Specification SIM Static Structure” Diagram Description:
Cutoff cannot be executed on a RecordSet that contains a ManagedRecord with isCaseFile = True (i.e., the ManagedRecord is a "Case File Record") that has not been "closed" (i.e., ManagedRecord.closedDate has been filled with a valid dateTime.)
Add following Constraint to the Cutoff Operation Description in Domain Model Class: Dispositions::Cutoff, Service Model Class: DispositionsSIM::Cutoff; and their diagrams
CaseFileClosure
Description: Cutoff cannot be executed on a RecordSet that contains a ManagedRecord with isCaseFile = True that has not been closed.
Actions taken:
January 21, 2010: received issue
April 25, 2011: closed issue
Discussion:
Issue 15109: There are Errors in the RMS.XSD (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: 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
Resolution: Merged into Issue 15212
Revised Text:
Actions taken:
March 2, 2010: received issue
April 25, 2011: closed issue
Issue 15110: In the RMS.XSD we have circularity between the rms and ap namespace (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: We can eliminate this by splitting out the party model (the only reference from ap to rms) into its own namespace
Resolution: Split out Party and Document from RMSDomain package to eliminate the circularity. Rename packages RmsDomain to RmsCore, Party to RmsParty and Document to RmsDocument.
Revised Text: Split out Party and Document from RMSDomain package to eliminate the circularity. Rename packages RmsDomain to RmsCore, Party to RmsParty and Document to RmsDocument.
Actions taken:
March 2, 2010: received issue
April 25, 2011: closed issue
Discussion:
Issue 15111: Do we need a root to reach everything in the RMS.XSD (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: 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
Resolution: Disposition Note: Merged into 50512
Resolution:
None
Revised Text: Unspecified
Revised Text:
Actions taken:
March 2, 2010: received issue
April 25, 2011: closed issue
Discussion:
Issue 15114: RecordKeeper is related to ManagedRecord. Shouldn't it be to RecordSet? (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: 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?
Resolution: 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.
Revised Text: Delete from Association Descriptions of ManagedRecord::ManagedRecord:
Association
Documents the ManagedRecord's currently assigned RecordKeeper. The current RecordKeeper is identified by the latest assigned RecordKeeper
From Class: Party::RecordKeeper
In the Role of: theKeeper
Multiplicity: 0..*
Description: The ManagedRecord's assigned RecordKeeper
To Class: ManagedRecord::ManagedRecord
In the Role of:: keeps
Multiplicity: 0..*
Add to Associiation Description of Dispositions::RecordSet
Association
Documents a RecordSet currently assigned to a RecordKeeper. The current RecordKeeper is identified by the latest assigned
RecordKeeper.From Class:Party::RecordKeeper
In the Role of: theKeeper
Multiplicity: 0..*
Description: The ManagedRecord's assigned RecordKeeper
To Class: Dispositions::RecordSet
In the Role of:: keeps
Multiplicity: 0..*
Change the “To Class:” in Association Description of Party (RecordKeeper to ManagedRecord) to (RecordKeeper to RecordSet)
Remove RecordKeeper from the Diagrams in the PIM for ManagedRecord and the ManagedRecord SIM
Add RecordKeeper to the Diagrams in PIM for Dispositions and Dispositions SIM where RecordSet is Documented.
Remove all Role subtypes from Party Static Structure diagram (these have been moved to the package RmsRoles.
Add the following Section
Package: RmsRoles
The RmsRoles package extends the Party package to include the roles necessary for assigning responsibility of actions and custodianship in a records management environment. It is not intended to represent the overall organization structure.
A party model in a records management context is related to the organizational structure of the organization in which records are being managed, but is not identical to it. The purpose of the model is to be able to express Provenance and to identify the Roles in the organization that attribute aspects of the Managed Record.
Update Figure RmsRoles Static Structure
The Party Model in this context is related to the organizational structure of the organization in which records are being managed, but is not identical to it. The purpose of the model is to be able to express Provenance and to identify the Roles in the organization that attribute aspects of the Managed Record.
Provenance is minimally specified by the top-level organization authorized as a valid organization for Provenance. If there is an organization that contains it, it is not instantiated in this model.
Provenance can be expressed in greater detail through a chain of suborganizations. However, at the discretion of the organization, some suborganizations are not expressed in the Provenance chain, in which case the Party's belonging to it are "collapsed" into its containing suborganization. These "suppressed" organizations are not instantiated in this model.
Though related to the overall organizational structure, there is no requirement for it to be wholly consistent. The intent is to provide the designation of Provenance consistent with the business practices of the organization.
Class: RmsRoles::Authority
Authority's are used to cite the Authority through which an action or assignment was authorized. Used for such things as an Annotation denoting security classification, the Suspension or SuspensionRevocation of a record, etc.
Attributes
Connections
Association
Relates the CategorizationSchema to the Authority that has approved it.
From Class: Category::CategorizationSchema
In the Role of: recordSchedule
Multiplicity: 0..*
Description: The approved CategorizationSchema
To Class: RmsRoles::Authority
In the Role of:: authority
Multiplicity: 1
Description: The Authority that approved the CategorizationSchema
Association
The Authority for the CaseFileRecordDefinition
From Class: ManagedRecord::CaseFileRecordDefinition
In the Role of: definition
Multiplicity: 0..*
Description: The authorized CaseFileRecordDefinition.
To Class: RmsRoles::Authority
In the Role of:: authority
Multiplicity: 1
Description: The Authority authorizing the CaseFileRecordDefinition.
Association
Associates a DispositionInstruction with the Authority that approved it.
From Class: RmsRoles::Authority
In the Role of: dispositionAuthority
Multiplicity: 1
Description: The Authority that approved the DispositionInstruction.
To Class: Dispositions::DispositionInstruction
In the Role of:: dispositionInstruction
Multiplicity: 0..*
Description: The DispositionInstruction approved by the Authority.
Association
The Authority under which the CaseFileAction was taken.
From Class: ManagedRecord::CaseFileAction
In the Role of: action
Multiplicity: 0..*
Description: The authorized CaseFileAction.
To Class: RmsRoles::Authority
In the Role of:: authority
Multiplicity: 1
Description: The Authority under which the CaseFileAction was performed.
Association
Associates an Annotation with the Party responsible for authorizing it.
From Class: RmsRoles::Authority
In the Role of: authority
Multiplicity: 0..1
Description: The Authority for the Annotation
To Class: Annotation::Annotation
In the Role of:: authorizedAnnotation
Multiplicity: 0..*
Description: The authorized Annotation.
Generalization
From Class: RmsRoles::Authority
To Class: Party::Role
AssociationClass
Records the authorized revocation of a particular DispositionSuspend.
From Class: Party::Authority
In the Role of: revocationAuthority
Multiplicity: 0..1
Description: The Authority authorizing the revocation of a DispositionSuspend.
To Class: Dispositions::DispositionSuspend
In the Role of:: revokedSuspension
Multiplicity: 0..1
Description: A DispositionSuspend revoked by the Authority.
Association
Associates an SuspendEvent with the Authority which declared it.
From Class: Dispositions::SuspendEvent
In the Role of: suspendEvent
Multiplicity: 0..*
Description: The authorized SuspendEvent.
To Class: Party::Authority
In the Role of:: authority
Multiplicity: 1
Description: The Authority declaring the SuspendEvent.
Class: RmsRoles::RecordCreator
Record Creator is a person, juridical person, organization or system (e.g., consolidation of real-time data into reports that are officially distributed.) However, the role must trace up to an organization (agency in the case of government)
Ultimately, only an agency (organization) has provenance. Provenance can be established "lower" in the organization as long as it ultimately resolves to the agency (organization) at the top-level.
Attributes
Connections
Association
Documents the Party which set-aside the ManagedRecord
From Class: ManagedRecord::ManagedRecord
In the Role of: setasideRecord
Multiplicity: 1..*
Description: The ManagedRecord.
To Class: RmsRoles::RecordCreator
In the Role of:: creator
Multiplicity: 1
Description: The Party that set-aside (created) the ManagedRecord. This has nothing to do with who created the Documents that comprise the ManagedRecord.
Generalization
From Class: RmsRoles::RecordCreator
To Class: Party::Role
Class: RmsRoles::RecordKeeper
The administrative entity, unit, office, or person responsible for the custody and ongoing management of the records during their active business use.
Attributes
Attribute: RecordKeeper.assignmentDate
Type: dateTime
Description: The date/time that a RecordKeeper was assigned to one or more ManagedRecords.
Connections
Association
Documents the RecordSet's currently assigned RecordKeeper. The current RecordKeeper is identified by the latest assigned RecordKeeper
From Class: RmsRoles::RecordKeeper
In the Role of: theKeeper
Multiplicity: 0..*
Description: The ManagedRecord's assigned RecordKeeper
To Class: Dispositions::RecordSet
In the Role of:: keeps
Multiplicity: 0..*
Description: The Party that serves as RecordKeeper for the ManagedRecord.
Association
Keeps the history of RecordKeeper's for specific RecordSets.
From Class: RmsRoles::RecordKeeper
In the Role of: next
Multiplicity: 0..1
Description: The next RecordKeeper (if there is no next, this is the current RecordKeeper.
To Class: RmsRoles::RecordKeeper
In the Role of:: previous
Multiplicity: 1
Description: The previous RecordKeeper.
Generalization
From Class: RmsRoles::RecordKeeper
To Class: Party::Role
Replace the diagram “RMS Domain Model Package” to reflect the new package structures and dependencies and rename to “RmsCore Package Structure”
Replace the diagram “RMS PIM Overview” to reflect the new high level package structure of the domain model
Actions taken:
March 4, 2010: received issue
April 25, 2011: closed issue
Discussion:
Issue 15212: The transformation algorithm from UML to XSD is inadequate for RMS purposes. (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature:
Severity:
Summary: 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.
Resolution: 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
Revised Text: Replace Section “Platform Specific Models” with:
Platform Specific Models
Two sets of Platform Specific Models are defined for the specification
• RMS Information Exchange XSD’s
• WSDL’s for RMS Web Service Definitions
These machine-readable files are considered normative parts of this specification.
RMS Information Exchange XSD’s
Records Management XML Schemas are based on the Document, Party, RmsCore, and AttributeProfile packages in the RmsPIM. They have two purposes:
1. They are used to import and export Managed Records via a compliant XML file.
2. They are used as the basis for forming XQuery/XPath query statements and responses to those statements.
Partitioning of XSD’s
An XSD is provided for every domain package partitioned among the four containing packages:
o rms-core
? annotation.xsd
? attributeprofile.xsd
? authenticity.xsd
? category.xsd
? dispositions.xsd
? managedrecords.xsd
? role.xsd
o document
? document.xsd
o attrbprofile
o party
? party.xsd
The correlation between the model packages and the XSD files is as follows:
Schema Model Pack1age XSD File
Annotation RmsPim/RmsCore/Annotations Annotations.xsd
AttributeProfile RmsPim/AttributeProfile AttributeProfile.xsd
Authenticity RmsPim/RmsCore/Authenticity Authenticity.xsd
Category RmsPim/RmsCore/Category Category. xsd
Dispositions RmsPim/RmsCore/Dispositions Dispositions. xsd
Document RmsPim/Document Document.xsd
ManagedRecords RmsPim/RmsCore/ManagedRecords ManagedRecords. xsd
Role RmsPim/RmsCore/RmsRoles Role.xsd
Party RmsPim/Party Party. xsd
RmsSet N/A RmsSet.xsd
• The namespaces for each domain package XSD are as follows:
o http://www.omg.org/spec/rms/v1.0/party
o http://www.omg.org/spec/rms/v1.0/rms-core/role
o http://www.omg.org/spec/rms/v1.0/document
o http://www.omg.org/spec/rms/v1.0/rms-core/annotation
o http://www.omg.org/spec/rms/v1.0/rms-core/category
o http://www.omg.org/spec/rms/v1.0/rms-core/managedrecords
o http://www.omg.org/spec/rms/v1.0/rms-core/dispositions
o http://www.omg.org/spec/rms/v1.0/rms-core/authenticity
o http://www.omg.org/spec/rms/v1.0/attrbprofile
• Each of the domain packages XSD’s contains a complexType which is named by concatenating the domain package name with “Set”. Its purpose is to serve when necessary as root element that is not semantically part of the domain package(s). Each is defined to have 0 to unbounded number of members of class type elements allowing the transfer of unrelated items should the business case require it.
• One exception to “one …Set” per Domain Package is the Dispositions Package which, due to its size, was partitioned within the XSD itself with five …Set complexType’s
o DispositionInstructionSet
o DispositionPlanSet
o DispositionRecordSets
o DispositionEventSet
o DispositionSuspendSet
• An additional XSD, RmsSet.xsd, is provided
o This XSD is a “collector” for the domain package XSD’s. The primary purpose of this XSD is to provide a container (root element) for exchanging RMS information that is not a semantic element, but an “abstract” container.
o Its namespace is targetNamespace=http://www.omg.org/spec/rms/v1.0/rms-set
o It imports all of the above domain package namespaces.
o It has a single complexType named “RmsSet” which contains a sequence of optional elements
? There is one element for each domain package.
? The element is of the …Set complexType from each of the domain packages.
UML to XSD Transformation Heuristics
The XSD’s were derived from the UML model using the following heuristic guide:
UML Classes
UML Classes are converted to xs:complexType statements the name of which is the classes name. Additionally an element is created with the same name (the class’s name) with the type of the class’s complexType, enabling any class to serve as a root element if it makes sense for the purpose of the information exchange.
Each Class contains an xs:sequence of xs:element’s for
• attributes with clauses for
o name=”attribute-name”
o type=”xs:attribute-type”
o minOccurs and maxOccurs statements to reflect multiplicity
• associations
o name=”class”+”ID”
? [The convention is to append the class name to which the association extends with ID forming, in effect, a “foreign key” to the class instance]
o type=xs:NCName
? [type=NCName is used in lieu of IDREF since under many business scenarios the target instance may not be present in the same XML document as the instance being transferred.]
o minOccurs and maxOccurs statements to reflect multiplicity on the terminating end of the association.
UML Association
The opposite end role of each UML Association becomes an element contained within a class (xs:complexType) participating in the association.
These elements are “peers” to the attributes (xs:elements) in the classes (xs:complexTypes) and are foreign keys pointing to the class instance(s) at the other end of the association, as explained in “Classes” above.
Association Classes
UML Association Classes are converted to Classes as defined above. UML Associations (defined above) are created between the Association Class and each of the classes participating in the association. Note there are no direct pointers between the associated classes.
Enumerations
Enumerations are converted to simpleType’s with name=”NameOfEnumerationClass”. A base for the type is declared via an xs:restriction that contains the xs:enumeration values.
WSDL’s for RMS Web Service Definitions
Ten WSDL files are provided; one for each of the following services.
o Annotations
o AttributeProfiles
o Authorities
o Categories
o Dispositions
o Documents
o ManagedRecords
o Query
o RecordAuthentications
o Parties
The WSDL files were created based on the corresponding service packages in the RmsServices package of the RmsPim. The correlation is as follows:
Service
Model Package
WSDL File
Service: Annotations
Package: RmsPim/RmsServices/RmsCoreServices/AnnotationsService
Annotations.wsdl
Service: Authorities
RmsPim/RmsServices/RmsCoreServices/ AuthoritiesService
Authorities.wsdl
Service: Categories
RmsPim/RmsServices/RmsCoreServices/ CategoriesServic
Categories.wsdl
Service: Dispositions
RmsPim/RmsServices/RmsCoreServices/ DispositionsService
Dispositions.wsdl
Service: Documents
RmsPim/RmsServices/RmsCoreServices/ DocumentsService
Documents.wsdl
Service: ManagedRecords
RmsPim/RmsServices/RmsCoreServices/ ManagedRecordsService
ManagedRecords.wsdl
Service: Query
RmsPim/RmsServices/RmsCoreServices/ Query Service
Query.wsdl
Service: RecordAuthentications
RmsPim/RmsServices/RmsCoreServices/ RecordAuthenticationsService
RecordAuthentications.wsdl
Service: AttributeProfiles
RmsPim/RmsServices/RmsUtilityServices/AttributeProfiles Service
AttributeProfiles.wsdl
Service: Parties
RmsPim/RmsServices/RmsUtilityServices/PartiesService
Parties.wsdl
Actions taken:
April 20, 2010: received issue
April 25, 2011: closed issue
Issue 15214: RMS would be better cast as a MOF model as opposed to a UML model (rms-ftf)
Click here for this issue's archive.
Source: International Business Machines (Mr. Sridhar Iyengar, siyengar(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary: 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)
Resolution: 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
Revised Text:
Actions taken:
April 20, 2010: received issue
April 25, 2011: closed issue
Discussion:
Issue 15228: managed record clarification (rms-ftf)
Click here for this issue's archive.
Source: Lockheed Martin (Mr. John Olden-Stahl, john.olden-stahl(at)lmco.com)
Nature: Uncategorized Issue
Severity:
Summary: 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?
Resolution: 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
Revised Text:
Actions taken:
April 23, 2010: received issue
April 25, 2011: closed issue
Issue 15671: Need convention to name referenced object via IDREF (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: 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
Resolution: Resolved as part of Issue 15212. The convention eventually adopted involved W3C type NCName rather than IDREF.
Revised Text: None
Revised Text:
Actions taken:
October 3, 2010: received issue
April 25, 2011: closed issue
Issue 15782: Service packages require operation definitions (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: 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
Resolution: Operation definitions have been added
Revised Text: In the section "Package: AnnotationsService" add the subsection: "Capabilities: AnnotationsService::Annotations", with the following text.
addAnnotation: Id
Scope Public
Description This operation provides the ability to add an annotation to a managed record. It requires the ID of the managed record as well as the Authority from which the annotation is coming. Parameters include the annotation to be added, the Id of the authority of the annotation and the Id of the creator of the annotation. The operation returns the Id of the annotation that was added.
Parameters annotation: Annotation {in}
authorityID: int {in}
creatorId: Id {in}
addAnnotationToRecord: Id
Scope Public
Description This operation allows a new Annotation to be added to a particular ManagedRecord. Parameters include the annotation to be added, the Id of the managed record, the Id of the authority for the annotation, and the Id of the creator of the annotation. The operation returns an acknowledgement indicating success or failure.
Parameters annotation: Annotation {in}
managedRecordId: Id {in}
authorityID: int {in}
creatorId: Id {in}
applyAnnotationToRecord: ack
Scope Public
Description This operation allows a particular Annotation to be applied to a particular ManagedRecord. Parameters include the Id of the annotation being added to the ManagedRecord, the Id of the managed record, and the Id of the party annotating the managed record. The operation returns an acknowledgement indicating success or failure.
Parameters annotationId: Id {in}
managedRecordId: Id {in}
annotatorId: Id {in}
getAnnotation: Annotation
Scope Public
Description This operation returns the annotation with a given Id. The only parameter is the Id of the annotation to be returned.
Parameters annotationId: Id {in}
getAnnotationsForRecord: Annotation
Scope Public
Description The getAnnotationsforRecord operation returns a list of the annotations for a record with a given ID. The only parameter is the Id of the managed record.
Parameters managedRecordId: Id {in}
RemoveAnnotationFromRecord: ack
Scope Public
Description This operation provides the ability to remove an annotation from a managed record. Parameters include the Id of the ManagedRecord and the Id of the annotation to be removed. The operation returns an acknowledgement indicating success or failure.
Parameters managedRecordId: Id {in}
annotationId: Id {in}
RemoveAnnotationsFromRecord: ack
Scope Public
Description This operation provides the ability to remove all annotations from a particular managed record. The only parameter is the Id of the managed record. The operation returns an acknowledgement indicating success or failure.
Parameters managedRecordId: Id {in}
In the section "Package: AuthoritiesService" add the subsection: "Capabilities: AuthoritiesService::Authorities", with the following text.
getAuthority: Authority
Scope Public
Description The getAuthory operation returns the Authority with the given Id.
Parameters authorityID: Id {in}
getListofAuthorities: Authority
Scope Public
Description The getListOfAhothorities operation returns a complete list of the Authorities within the system.
Parameters
In the section "Package: CategoriesService" add the subsection: "Capabilities: CategoriesService::Categories", with the following text.
getActiveRecordSet: DispositionPlan
Scope Public
Description This operation returns the active RecordSet for the RecordCategory if one exists. The only parameter is the category Id.
Parameters categoryID: Id {in}
getCategorizationSchema: CategorizationSchema
Scope Public
Description This operation returns the CategorizationSchema with the given name.
Parameters schemaName: String {in}
getCategorizationSchema: CategorizationSchema
Scope Public
Description This operation returns the CategorizationSchema with the given Id.
Parameters id: Id {in}
getCategoryForRecord: RecordCategory
Scope Public
Description This operation returns the RecordCategory for a particular ManagedRecord.
Parameters managedRecordId: Id {in}
getDispositionInstruction: DispositionInstruction
Scope Public
Description This operation returns the current DispositionInstruction associated with the RecordCategory specified by the categoryId.
Parameters categoryId: Id {in}
getRecordCategoryByName: RecordCategory
Scope Public
Description This operation returns the RecordCategory with the given name.
Parameters name: String {in}
setCategoryForRecord: ack
Scope Public
Description This operation assigns a ManagedRecord to a RecordCategory. Must notify the Dispositions service to add the record to the appropriate RecordSet. A ManagedRecord can be in only one RecordCategory at a time. The operation returns an acknowledgement indicating success or failure.
Parameters managedRecordId: Id {in}
recordCategoryName: String {in}
setCategoryForRecordSet: ack
Scope Public
Description This operation sets all ManagedRecords in the RecordSet to the RecordCategory with the given Id. The operation returns an acknowledgement indicating success or failure.
Parameters categoryId: Id {in}
recordSet: RecordSet {in}
In the section "Package: DispositionsService" add the subsection: "Capabilities: DispositionsService::Dispositions", with the following text.
addRecordToDispostionRecordSet: ack
Scope Public
Description This operation adds a record to a recordset for a disposition instruction with a given id. Parameters include the id of the managed record and the disposition instruction. The operation returns an acknowledgement of whether or not the operation executed successfully.
Parameters managedRecordId: Id {in}
instructionId: Id {in}
addSuspendForEvent: ack
Scope Public
Description This operation adds a suspension for a particular suspend event. This typically be the addition of a disposition suspend against another recordset. The operation returns an acknowledgement of whether or not the operation executed successfully.
Parameters suspendEventId: Id {in}
recordSetId: Id {in}
dispositionSuspend: DispositionSuspend {in}
calculateCutoffDate: TimeStamp
Scope Protected
Description This operation is to be implemented by the provider to determine when a cutoff date will occur.
Parameters periodString: String {in}
calculatePeriod: DateRange
Scope Protected
Description This operation is to be implemented by the provider to determine the length of a period.
Parameters periodString: String {in}
getActiveRecordSetForDispositionInstruction: RecordSet
Scope Public
Description This operation returns a recordset for the disposition instruction with the given id. If there is no disposition instruction for a category then the default instruction should be returned. If an instruction has not been set and no default is set, an exception should be raised.
Parameters instructionId: Id {in}
getDispositionInstruction: DispositionInstruction
Scope Public
Description This operation returns the disposition instruction with the given id.
Parameters dispositionInstructionId: Id {in}
getDispositionPlanForRecordSet: DispositionPlan
Scope Public
Description This operation returns the disposition plan for a recordset with a given id.
Parameters recordSetId: Id {in}
getRecordSetForInstructionByPeriod: RecordSet
Scope Public
Description This operation returns the RecordSet for a particular RecordCategory that was active during the time period indicated by the periodIncludeDate. The active period runs from the RecordSet.periodStartDate to the RecordSet.periodEndDate. Parameters include the id of the instruction and a date the active period must include.
Parameters instructionID: Id {in}
periodIncludeDate: TimeStamp {in}
getSuspensionsForRecord: DispositionSuspend
Scope Public
Description This operation returns an array of suspensions for a managed record with a given id.
Parameters managedRecordId: Id {in}
getSuspensionsForRecordSet: DispositionSuspend
Scope Public
Description This operation returns an array of suspensions for a recordset with a given id.
Parameters recordSetId: Id {in}
handleEvent: ack
Scope Public
Description This operation processes action events related to dispositions. The operations includes parameters for the event type and the event date. The operation returns an acknowledgement of whether or not the operation executed successfully.
Parameters eventType: ActionEventSpecification {in}
eventDate: TimeStamp {in}
revokeSuspend: ack
Scope Public
Description This operation revokes the suspension with the given id. The parameters include the id of the disposition suspension and the suspension revocation. The operation returns an acknowledgement of whether or not the operation executed successfully.
Parameters dispositionSuspendId: Id {in}
revocation: SuspensionRevocation {in}
revokeSuspendForEvent: ack
Scope Public
Description This operation revokes all suspensions associated with a particular suspend event. The parameters include the id of the suspend event and the suspension revocation. The operation returns an acknowledgement of whether or not the operation executed successfully.
Parameters SuspendEventId: Id {in}
revocation: SuspensionRevocation {in}
save: ack
Scope Protected
Description This private operation represents a responsibility of any implementation of the Dispositions service to be able to save a given object.
Parameters object: Object {in}
suspendRecord: ack
Scope Public
Description This operation places a suspension on a particular record. If the record is part of a recordset with additional managed records then a separate recordset will be created for that record and the suspension will be associated with the new recordset. Parameters include the disposition suspension and the id of the managed record to be suspended. The operation returns an acknowledgement of whether or not the operation executed successfully.
Parameters dispositionSuspend: DispositionSuspend {in}
managedRecordId: Id {in}
suspendRecordSet: ack
Scope Public
Description This operation places a suspension on an entire recordset with the given id. Parameters include the disposition suspension and the id of the recordset to be suspended. The operation returns an acknowledgement of whether or not the operation executed successfully.
Parameters dispositionSuspend: DispositionSuspend {in}
recordSetId: Id {in}
suspendRecordSetForEvent: ack
Scope Public
Description This operation a recordset based on a suspend event. The operation returns an acknowledgement of whether or not the operation executed successfully.
Parameters suspendEvent: SuspendEvent {in}
recordSetId: Id {in}
In the section "Package: DocumentsService" add the subsection: "Capabilities: DocumentsService::Documents", with the following text.
destroyDocument: ack
Scope Public
Description This operation removes the Document from the Records Management Environment. The operation returns an acknowledgement indicating success or failure.
Parameters documentId: Id {in}
getDocument: Document
Scope Public
Description This operation returns the Document associated with the docid.
Parameters docId: Id {in}
saveDocument: Id
Scope Public
Description This operation "uploads" a Document to the Records Management Environment along with its type and format. It returns with the system assigned Id.
Parameters document: Document {in}
type: DocumentType {in}
format: DocumentFormat {in}
setDocumentType: ack
Scope Public
Description This operation creates a DocumentType The operation returns an acknowledgement indicating success or failure.
Parameters docType: DocumentType {in}
In the section "Package: ManagedRecordsService" add the subsection: "Capabilities: ManagedRecordsService::ManagedRecords", with the following text.
addCaseFilePart: ack
Scope Public
Description This operation adds a document with a given document id as a record part of a case file (i.e. a managed record with isCaseFile set to true) with the given record id. The operation returns an acknowledgement of the success or failure of the operation.
Parameters docId: Id {in}
caseFileId: Id {in}
addRecordPart: ack
Scope Public
Description This operation adds a document with a given document id as a record part of a managed record with the given record id. The operation returns an acknowledgement of the success or failure of the operation.
Parameters docId: Id {in}
managedRecId: Id {in}
appendCaseFilePart: ack
Scope Public
Description This operation adds a RecordPart with a pointer to a document with a given document id immediately following the RecordPart with the given id to the managed record with the given record id. The operation returns an acknowledgement of the success or failure of the operation.
Parameters docId: Id {in}
recordId: Id {in}
recordPartId: Id {in}
associateRecords: ack
Scope Public
Description This operation creates an association between the originating record and another record. The type of association is specified using the associationType enumeration. The operation returns an acknowledgement of the success or failure of the operation.
Parameters originatingRecordId: Id {in}
associationType: enum {in}
recordId: Id {in}
captureRecord: managedRecId
Scope Public
Description This operation captures a new managed record for a document with the given document id. The operation also takes the id of the record keeper, the id of the record creator, and the id of the authority responsible for the record. The operation returns the id of the new managed record.
Parameters docId: Id {in}
managedRecord: ManagedRecord {in}
recKeeperId: Id {in}
recCreatorId: Id {in}
authorityId: Id {in}
isCaseFile: Boolean {in}
destroyRecord: ack
Scope Public
Description This operation removes the managed record with the given id from the system and returns an acknowledgement of the success or failure of the operation.
Parameters managedRecordId: Id {in}
getCurrentProvenance: Id
Scope Public
Description This operation returns the id of the Party with provenance for the managed record with the given id.
Parameters recordID: Id {in}
getProvenance: ProvenanceAssociation
Scope Public
Description This operation returns the provenance association for the record with the given record id.
Parameters recordID: Id {in}
getRecord: ManagedRecord
Scope Public
Description This operation returns the managed record associated with the given record id.
Parameters managedRecordId: Id {in}
getRecordKeeper: Id
Scope Public
Description This operation returns the id of the current record keeper of the record with the given id.
Parameters managedRecordId: Id {in}
getRecordKeeper: RecordKeeper
Scope Public
Description This operation returns the record keeper for the record with the given record id.
Parameters managedRecordId: Id {in}
getRecordKeeperHistory: RecordKeeper
Scope Public
Description This operation returns a list of record keepers of the record keepers of the record with the given id.
Parameters managedRecordId: Id {in}
getRecordLinks: ManagedRecordAssociation
Scope Public
Description This operation returns a list of managed record associations for the record with the given record id.
Parameters managedRecordId: Id {in}
removeAssociation: ack
Scope Public
Description This operation removes the ManagedRecordAssociationMember element from the ManagedRecordAssociation. If there is only one other ManagedRecord connected to the ManagedRecordAssociation then the association should be removed. The operation returns an acknowledgement of the success or failure of the operation.
Parameters associationId: Id {in}
removeCaseFilePart: ack
Scope Public
Description This operation removes the RecordPart with the given recordPartId from the ManagedRecord with the given recordId.
Parameters recordId: Id {in}
recordPartId: Id {in}
replaceCaseFilePart: ack
Scope Public
Description This operation replaces the RecordPart with an id of recordPartId on the managedRecord with the an id of recordId with a new RecordPart that points to a Document with an id of docId.
Parameters docId: Id {in}
recordId: Id {in}
recordPartId: Id {in}
setProvenance: ack
Scope Public
Description This operation sets the provenance for the record to the party with the given party id and returns an acknowledgement of the success or failure of the operation.. This operation needs to ensure that the RecordKeeper is within the organization that now has provenance.
Parameters managedRecordID: Id {in}
partyID: Id {in}
setRecordKeeper: ack
Scope Public
Description This operation sets the Party with the given id as the record keeper for the record with the given record id at the assignment date. The operation returns an acknowledgement of the success or failure of the operation.
Parameters partyId: Id {in}
managedRecordId: Id {in}
assignmentDate: TimeStamp {in}
setRecordKeeper: ack
Scope Public
Description This operation sets the record keeper id for the record with the given id to the party id passed to the operation. This operation must ensure that the Party associated with the PartyId parameter is in the Provenance Structure identified through the most recent ProvenanceAssociation. The operation returns an acknowledgement of the success or failure of the operation.
Parameters recordID: Id {in}
partyID: Id {in}
transferRecord: ack
Scope Public
Description This operation marks a record with the given id as being transferred as of the transfer date. The operation returns an acknowledgement of the success or failure of the operation.
Note: This operation may no longer be needed.
Parameters managedRecId: Id {in}
transferDate: TimeStamp {in}
In the section "Package: QueryService" add the subsection: "Capabilities: QueryService::Queries", with the following text.
query: String
Scope Public
Description This operation passes an XQuery/Xpath string to the Records Management Environment. The response is an XML string formatted according to the RMS XSD.
Parameters queryExpression: String {in}
In the section "Package: RecordAuthenticationsService" add the subsection: "Capabilities: RecordAuthenticationsService::RecordAuthentications", with the following text.
authenticateRecord: Boolean
Scope Public
Description This operation calculates the AuthenticationResult for the ManagedRecord and compares it to the AuthenticationBase. It returns Boolean true if they are the same, and false if they are not.
Parameters ManagedRecord: ManagedRecord {in}
changeAuthenticationMethod: ack
Scope Public
Description This operation enables the change of AuthenticationMethod of a ManagedRecord from an old AuthenticationMethod to the current AuthenticationMethod. It causes the generation of a new AuthenticationBase using the new AuthenticationMethod. The operation returns an acknowledgement indicating success or failure.
Parameters oldAMId: Id {in}
newAMId: Id {in}
managedRecordId: Id {in}
createAuthenticationBase: ack
Scope Public
Description This operation calculates the AuthenticationBase for the ManagedRecord identified by the managedRecordId using the current AuthenticationMethod. The operation returns an acknowledgement indicating success or failure.
Parameters managedRecordId: Id {in}
createAuthenticationBaseUsingMethod: ack
Scope Public
Description The operation establishes a new AuthenticationBase for a ManagedRecord using a particular AuthenticationMethod passed as its ID. The operation returns an acknowledgement indicating success or failure.
Parameters managedRecordId: Id {in}
methodId: Id {in}
createAuthenticationBaseUsingMethod: ack
Scope Private
Description The operation establishes a new AuthenticationBase for a ManagedRecord using a particular AuthenticationMethod which is passed as a parameter. The operation returns an acknowledgement indicating success or failure.
Parameters managedRecord: ManagedRecord {in}
authenticationMethod: AuthenticationMethod {in}
generateAuthenticationResult: AuthenticationResult
Scope Protected
Description This operation returns an AuthenticationResult calculated using the current AuthenticationMethod.
Parameters managedRecord: ManagedRecord {in}
generateAuthenticationResult: AuthenticationResult
Scope Protected
Description This operation returns an AuthenticationResult calculated using the specified AuthenticationMethod.
Parameters managedRecord: ManagedRecord {in}
authenticationMethodId: AuthenticationMethod {in}
getAuthenticationResult: AuthenticationResult
Scope Protected
Description This operation returns the AutheticationResult for the ManagedRecord.
Parameters managedRecordId: Id {in}
retireAuthenticationMethod: ack
Scope Public
Description This operation is used to mark the retirement date of an AuthenticationMethod. The operation returns an acknowledgement indicating success or failure.
Parameters amId: Id {in}
retireDate: Timestamp {in}
setIAuthenticationMethodnForceDate: ack
Scope Public
Description This operation marks when a new AuthenticationMethod will be put inForce. The operation returns an acknowledgement indicating success or failure.
Parameters amId: Id {in}
inForceDate: TimeStamp {in}
In the section "Package: AttributeProfiles Service" add the subsection: "Capabilities: AttributeProfiles Service::AttributeProfiles", with the following text.
getAttributableClassAttributes: DataProfileAttrDefn
Scope Public
Description This operation returns an array of the attributes definitions for a particular attributable class and profile.
Parameters attributableClassId: Id {in}
getAttributableClasses: Attribute Profile SIM Static Structure
Scope Public
Description This operation returns an array of AttributableClass's in the system for a given data profile.
Parameters dataProfileId: Id {in}
getAttributeValue: AttributeValue
Scope Public
Description This operation returns the attribute value with the given name.
Parameters attribObjectId: Id {in}
attributeName: string {in}
getAttributeValues: AttributeValue
Scope Public
Description This operation returns an array of attribute values for the attributable object with the given id.
Parameters attribObjectId: Id {in}
registerAttributableObject: Id
Scope Public
Description This operation provides the ability to register an object so that additional attributes can be maintained for it.
Parameters attributableClassId: Id {in}
objectId: Id {in}
objectType: string {in}
setAttributeValue: void
Scope Public
Description This operation provides the ability to set an attribute value for an attributable object.
Parameters attribObjId: Id {in}
attributeValue: AttributeValue {in}
profileAttrDefnId: Id {in}
In the section "Package: PartiesService" add the subsection: "Capabilities: PartiesService::Parties", with the following text.
getAssignedParties: PartyRoles[]
Scope Public
Description This operation returns the collection of PartyRoles, that have filled the Role designated by the roleId.
Parameters roleId: Id {in}
getAssignedParty: Party
Scope Public
Description This operation returns the Party that filled a particular Role as designated by the by the roleID on the effectiveDate.
Parameters roleId: Id {in}
effectiveDate: TimeStamp {in}
getParent: Party
Scope Public
Description This operation returns the Party which is the immediate Parent of the Party designate by the partyId.
Parameters partyId: Id {in}
getParty: Party
Scope Public
Description This operation returns the Party associated with the particular partyId.
Parameters partyID: Id {in}
getSubordinates: Party[]
Scope Public
Description This operation returns the collection of Party's which are subordinate to the Party designated by the partyId on the effectiveDate.
Parameters partyId: Id {in}
effectiveDate: TimeStamp {in}
Actions taken:
October 26, 2010: received issue
April 25, 2011: closed issue
Issue 15871: RecordKeepers and Suspensions Services no longer exist but their ports are in the specification and the XMI file (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Larry L. Johnson, larry.johnson(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: Removing the ports will resolve problems of untyped ports in the XMI.
Resolution: 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.
Revised Text: see pt/2010-12-18 pages 70 - 71
Actions taken:
December 7, 2010: received issue
April 25, 2011: closed issue
Discussion: