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 14030: FTF needs to use the appropriate namespace URLs for the XML schemas and WSDL documents
Issue 14124: Exception Architecture
Issue 14125: Need to add CRUD operations for RecordCreators
Issue 14126: Do we need additional Id's in CategoriesService?
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 14130: Add definition/discussion of "Record Schedule"
Issue 14131: We must state that a hold on record attributes must disallow changes or updates of any sort.
Issue 14132: What happens on "destruction" or "transfer"
Issue 14133: How many In Force authentication methods can there be? Does there have to be at least one in force at all times?
Issue 14134: RecordCreator and RecordKeeper must have Agency (or the top level organization)
Issue 14442: Hierarchical composition of case file parts
Issue 14443: Optional document association for case file parts
Issue 14444: Case file part reference support
Issue 14445: Cardinality on case file part definitions
Issue 14967: Assurance of Document Integrity on Open
Issue 14968: We currently do not require any particular time or event that the authentication be done
Issue 14969: Clarify that we are using the steriotypes from SOAML
Issue 14970: Would a caseDefinition, as core object in case management extend caseFileDefinition, or associate with it?
Issue 14971: Are we missing a Repository Service?
Issue 14972: Double Delete Authority
Issue 14973: Need to provide formal description of behavior for operations
Issue 14974: Need to provide formal description of behavior for operations
Issue 14975: Filter required for operation that identifies MR's that are candidates for disposition.
Issue 14976: Clarify use of terms that occur in both RMS and DoD 5015.02
Issue 14988: Content of RecordPart could be more XML friendly
Issue 14996: Are effective and end dates required fields in the Party model?
Issue 14997: Package Diagram is Incomplete
Issue 14999: Documents shared among CaseFile's and "vanilla" ManagedRecord's
Issue 15000: Relationship of CaseFile "Close" and RecordSet "Cutoff" Operations
Issue 15002: Specification of Attribute Sizes
Issue 15021: We need to be able to add Annotations to RecordPart’s as well as ManagedRecords
Issue 15022: Clarify the bi-directional relationships among documents, cases, and parts
Issue 15023: Explicit or implicit transaction model is needed
Issue 15024: Need bundled operation requests
Issue 15025: We need to support management of a record in place
Issue 15026: Assure minimum required attribution
Issue 15108: CaseFilePart description is incorrect
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 15211: We need a datum characteristic that indicates if it is systemAssigned
Issue 15212: The transformation algorithm from UML to XSD is inadequate for RMS purposes.
Issue 15213: The RMS XMI is not well formed & does not play well with other tools
Issue 15214: RMS would be better cast as a MOF model as opposed to a UML model
Issue 15226: There is no reference for Record Sets Operations in the services
Issue 15228: managed record clarification
Issue 15229: The Spec does not define a schema for the query string
Issue 15230: Using plain Xquery can introduce security issues
Issue 15671: Need convention to name referenced object via IDREF
Issue 15672: Between DataProfileAttrDefn and AttributableClassType, the role names are misleading
Issue 15673: Are W3C ID’s globally unique, or are there further qualifications we need to put on our ID’s
Issue 15674: AttributeValue.partyID in the PIM should be an association… it would be a partyID in the PSM
Issue 15675: Many” multiplicity is not accommodated by the XSD
Issue 15676: There is no linkage in the XSD between DocumentType and DataProfileAttrDefn
Issue 15677: Navigability will dictated in the PIM. We must revisit the navigability of each association
Issue 15678: document.id type is “string”, it should be “ID”.
Issue 15685: No need for RecordCreator
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 14030: FTF needs to use the appropriate namespace URLs for the XML schemas and WSDL documents (rms-ftf)
Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Revision
Severity: Significant
Summary:
The FTF needs to use the appropriate namespace URLs for the XML schemas and WSDL documents associated with the RMS spec. The current draft of the SMSC format for these URIs is at: http://www.omg.org/members/cgi-bin/doc?smsc/09-06-03.pdf
Resolution:
Revised Text:
Actions taken:
June 24, 2009: received issue
Issue 14124: Exception Architecture (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 practical system requires an effective exception architecture.
Nominally 80% of the normal operation of a given system is in exception processing, not to be confused with related concepts of system errors or failure.
Need to devise an exception architecture suitable for informing user of errors and to allow developers to debug unexpected responses.
[JRMS Remaining Issue]
Resolution:
Revised Text:
Actions taken:
July 28, 2009: received issue
Discussion:
Issue 14125: Need to add CRUD operations for RecordCreators (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: RecordCreatorsService
[JRMS Remaining Issue]
Resolution:
Revised Text:
Actions taken:
July 28, 2009: received issue
Discussion:
Issue 14126: Do we need additional Id's in CategoriesService? (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: CategoriesService: Do we need Ids for CategorySchemas and RecordCategories? Is Name unique or the path down the form the top to the record category?
The presumed concept of RMS operation is that most communication will be done between the client & server via the ID's of the objects being referenced. We need to assure we have ID's on all entities that require it.
[JRMS Remaining Issue]
Resolution:
Revised Text:
Actions taken:
July 28, 2009: received issue
Discussion:
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 14130: Add definition/discussion of "Record Schedule" (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 current discussion of Record Schedule and its relationship to categories is inadequate.
[JRMS Remaining Issue]
Resolution:
Revised Text:
Actions taken:
July 28, 2009: received issue
Discussion:
Issue 14131: We must state that a hold on record attributes must disallow changes or updates of any sort. (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 must state that a hold on record attributes must disallow changes or updates of any sort, or enumerate the specific changes that are allowed, if any.
[JRMS Remaining Issue]
Resolution:
Revised Text:
Actions taken:
July 28, 2009: received 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 14133: How many In Force authentication methods can there be? Does there have to be at least one in force at all times? (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: How many In Force authentication methods can there be? Does there have to be at least one in force at all times?
[JRMS Remaining Issue]
Resolution:
Revised Text:
Actions taken:
July 28, 2009: received 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 14442: Hierarchical composition of case file parts (rms-ftf)
Click here for this issue's archive.
Source: Cordys (Mr. Henk de Man, hdman(at)cordys.com)
Nature: Uncategorized Issue
Severity:
Summary: Description: This enables building a structure like an order with embedded lines. Example: Sales order for professional product, e.g. aircraft (order from e.g. Continental to Boeing). There’s a lot of “documents”, but there’s also a lot of “typical application data”, such as in CRM, ERP, etc. systems. It should be possible that case files refer to both in combination.
Resolution:
Revised Text:
Actions taken:
September 28, 2009: received issue
Issue 14443: Optional document association for case file parts (rms-ftf)
Click here for this issue's archive.
Source: Cordys (Mr. Henk de Man, hdman(at)cordys.com)
Nature: Uncategorized Issue
Severity:
Summary: Description: Case file parts are attributable. To express structured data, you not always need an associated document. It should be possible to explicitly mark a case file part as 'no document expected'.
Resolution:
Revised Text:
Actions taken:
September 28, 2009: received issue
Issue 14444: Case file part reference support (rms-ftf)
Click here for this issue's archive.
Source: Cordys (Mr. Henk de Man, hdman(at)cordys.com)
Nature: Uncategorized Issue
Severity:
Summary: Description: This allows referencing one case file part from another, potentially in another case file. This would allow referencing e.g. a customer from an order.
Resolution:
Revised Text:
Actions taken:
September 28, 2009: received issue
Issue 14445: Cardinality on case file part definitions (rms-ftf)
Click here for this issue's archive.
Source: Cordys (Mr. Henk de Man, hdman(at)cordys.com)
Nature: Uncategorized Issue
Severity:
Summary: Description: This defines the number of times a certain case file part can occur in a context (the case file or a case file part – once hierarchy is supported). Example: an auto damage claim case, whereby four photo’s would be required, e.g. one from each side of the car. So, cardinality (multiplicity) of part “Car body photo” would be 4 (associated to the corresponding case file part definition).
Resolution:
Revised Text:
Actions taken:
September 28, 2009: received issue
Issue 14967: Assurance of Document Integrity on Open (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Daryll Prescott, drp(at)tethersend.com)
Nature:
Severity:
Summary: The RM environment when an authorized user wants to "open" a record, a copy of the ManagedRecord must be provided to the user to open, or placed in a temp directory to open to preclude any possibility of any change
Resolution:
Revised Text:
Actions taken:
January 14, 2010: received issue
Discussion:
Issue 14968: We currently do not require any particular time or event that the authentication be done (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Daryll Prescott, drp(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: We need to require that it be done on capture. Should we require other events like retrieval? (This would get into the business process of the organization
Resolution:
Revised Text:
Actions taken:
January 14, 2010: received issue
Issue 14969: Clarify that we are using the steriotypes from SOAML (rms-ftf)
Click here for this issue's archive.
Source: Everware-CBDI (Mr. John C. Butler, jbutler(at)everware-cbdi.com)
Nature: Uncategorized Issue
Severity:
Summary: Clarify that we are using the steriotypes from SOAML
Resolution:
Revised Text:
Actions taken:
January 14, 2010: received issue
Discussion:
Issue 14970: Would a caseDefinition, as core object in case management extend caseFileDefinition, or associate with it? (rms-ftf)
Click here for this issue's archive.
Source: Cordys (Mr. Henk de Man, hdman(at)cordys.com)
Nature: Uncategorized Issue
Severity:
Summary: Would a caseDefinition, as core object in case management extend caseFileDefinition, or associate with it? (Henk de Man, 20090225)
Resolution:
Revised Text:
Actions taken:
January 14, 2010: received 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 14972: Double Delete Authority (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Daryll Prescott, drp(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: There needs to be a double delete authority, two seperate persons (personalities) in the system before something that is identified as a record can be dispositioned. (Daryll Prescott, 20091203)
Resolution:
Revised Text:
Actions taken:
January 14, 2010: received issue
Discussion:
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 14974: 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:
Revised Text:
Actions taken:
Discussion:
Issue 14975: Filter required for operation that identifies MR's that are candidates for disposition. (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: We need to provide the capability to include/exclude records that are on hold for Disposition Candidates identification. (Bill Manago, 20091204)
Resolution:
Revised Text:
Actions taken:
January 14, 2010: received issue
Discussion:
Issue 14976: Clarify use of terms that occur in both RMS and DoD 5015.02 (rms-ftf)
Click here for this issue's archive.
Source: TethersEnd Consulting (Mr. Daryll Prescott, drp(at)tethersend.com)
Nature: Uncategorized Issue
Severity:
Summary: There is probably a need to consider language talking about the inherent conflict arising from the proper use of terms in the OMG RMS Spec and the use those same words have in the DoD 5015.2 Standard. For example, the word "Agency" is specified in the OMG Spec but it is addressed differently in the 5015.02. The 5015.02 operates more from the individual/action officer level with regard to this and the OMG Spec applies itself to satisfying 44 U.S.C. and 36 C.F.R. (Daryll Prescott, 20091207)
Resolution:
Revised Text:
Actions taken:
January 14, 2010: received issue
Discussion:
Issue 14988: Content of RecordPart could be more XML friendly (rms-ftf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary: As it is currently designed, the RecordPart requires the content to be stored as a hexBinary blob. This is very convenient to deal with non-XML data, but it's considerably limiting when dealing with XML data.
Considering the emergence of XML databases, if the content of the record part were stored as regular XML, I could perform a XQuery statement that could traverse both the RMS-related data as well as the record-specific data.
This is also aligned with the emergence of XMLSec (allowing digital signatures embedded in XML documents).
The simplest way to solve this issue (while providing backward compatibility) would be to provide a choice between "content" - which would still be the hexBinary blob - and a new "xmlContent" element - which would then be of the type "any" and then could store any arbitrary XML document.
Resolution:
Revised Text:
Actions taken:
January 19, 2010: received issue
Issue 14996: Are effective and end dates required fields in the Party model? (rms-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: Name: Daniel Ruoso
Company: Prefeitura de Fortaleza
mailFrom: daniel@ruoso.com
Notification: Yes
Specification: RMS
For the fields effectiveStartDate and effectiveEndDate in Role, that information might not be known at the time the record is first captured. Are these fields required? If not, how do I work around that?
Resolution:
Revised Text:
Actions taken:
January 20, 2010: received issue
Discussion:
Issue 14997: Package Diagram is Incomplete (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: In the specification the package diagram does not include, for example, "Disposition". (Larry Johnson, 20091209
Resolution:
Revised Text:
Actions taken:
January 20, 2010: received issue
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 15002: Specification of Attribute Sizes (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: DoD 5015.02 does not specify field sizes. Nor does RMS in most cases. The description of a photograph might be adequately handled by 500 characters in one agency whereas another agency may require 50K characters. If the size is specified, what happens to inter-operability?
Resolution:
Revised Text:
Actions taken:
January 22, 2010: received issue
Discussion:
Issue 15021: We need to be able to add Annotations to RecordPart’s as well as ManagedRecords (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: Among other things, Annotations are used to tag ManagedRecord's with their security designations. There are situations in which only some RecordPart's are classified, therefore we need to be able to annotate RecordPart's separately. There was discussion of allowing Annotation's to Document's directly, but it was pointed out that there are situations in which a Document is not classified, but in the presence of another Document it is.
Resolution:
Revised Text:
Actions taken:
February 1, 2010: received issue
Issue 15022: Clarify the bi-directional relationships among documents, cases, and parts (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: Issue identified in the San Antonio TC RMS-FTF Meeting
Resolution:
Revised Text:
Actions taken:
February 1, 2010: received issue
Issue 15023: Explicit or implicit transaction model is needed (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: Our current service model often requires numerous operations to accomplish a task which must be completed or else the repository will be inconsistent. The task of setting aside a record, for example, is not a single operational call. Should connection be lost between the client server, or any operation fail, the repository can be left in an inconsistent state. This violates one of RMS original design principles
Resolution:
Revised Text:
Actions taken:
February 2, 2010: received issue
Issue 15024: Need bundled operation requests (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: Many of our operations operate on one object at a time. For efficiency a single call to perform the same action, or to provide multiple instances of object values needs to be accommodated. (e.g., return sets of id's, set many attribute values on an attributable object at one time, set-aside many records at a time.)
Resolution:
Revised Text:
Actions taken:
February 2, 2010: received issue
Discussion:
Issue 15025: We need to support management of a record in place (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: This is a concept that has been an important design criteria for RMS from the beginning.
We must assure that all fields and operations for accomplishing this are provided.
Resolution:
Revised Text:
Actions taken:
February 2, 2010: received issue
Issue 15026: Assure minimum required attribution (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: To fit the broadest spectrum of business processes we need to assure that only the absolutely necessary attributes for records management are required.
Resolution:
Revised Text:
Actions taken:
February 2, 2010: received issue
Issue 15108: CaseFilePart description is incorrect (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 CaseFilePart description does not properly reference CaseFilePartDefinition concerning constraints on the CaseFilePart
Resolution:
Revised Text:
Actions taken:
March 2, 2010: received 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 15211: We need a datum characteristic that indicates if it is systemAssigned (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: For AttributeProfiles it is important to distinguish between user entered and system entered fields.
Resolution:
Revised Text:
Actions taken:
April 20, 2010: received issue
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 15213: The RMS XMI is not well formed & does not play well with other tools (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 XMI is not well formed & does not play well with other tools. This problem may correct itself since EA is participating in the XMI interchange working group. The original XMI was generated with V7.1. (MPG used a much later version). We will keep our tools up to date and stay in communication with Sparx to see if this issue can be resolved
Resolution:
Revised Text:
Actions taken:
April 20, 2010: received issue
Discussion:
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 15226: There is no reference for Record Sets Operations in the services (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: The disposition plan is executed against a record set,
but the spec does not define how managed records are added to a record set. Is there some insight into the expectation?
Resolution:
Revised Text:
Actions taken:
April 23, 2010: received issue
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 15229: The Spec does not define a schema for the query string (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: Query Service mentions that input parameter qualifies the requested elements and the return string contains the elements that match the request. The Spec does not define a schema for the query string.
Resolution:
Revised Text:
Actions taken:
April 23, 2010: received issue
Issue 15230: Using plain Xquery can introduce security issues (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: Using plain Xquery can introduce security issues when it comes to authentications and authorization. Has this approach been revised?
Resolution:
Revised Text:
Actions taken:
April 23, 2010: received 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 15672: Between DataProfileAttrDefn and AttributableClassType, the role names are misleading (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: For example “type” should be “attributableClassType”; all the “definition” (4 of them) should be “attributeDefinition
Resolution:
Revised Text:
Actions taken:
October 3, 2010: received issue
Issue 15673: Are W3C ID’s globally unique, or are there further qualifications we need to put on our ID’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: We presume global uniqueness in our ID scheme. Is that assured by the W3C type or do we require further clarification of intent of identifiers.
Resolution:
Revised Text:
Actions taken:
October 3, 2010: received issue
Issue 15674: AttributeValue.partyID in the PIM should be an association… it would be a partyID in the PSM (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 list a party ID as an attribute in the style of a foreign key in the PIM. Generally we explicitly model associations in the PIM. It would however remain a foreign key in the PSM XSD.
Resolution:
Revised Text:
Actions taken:
October 3, 2010: received issue
Issue 15675: Many” multiplicity is not accommodated by the 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: For example, an AttributeClassType can have many DataProfileAttrDefn’s (maxoccurs=”unbounded”, which is the default).
Resolution:
Revised Text:
Actions taken:
October 3, 2010: received issue
Issue 15676: There is no linkage in the XSD between DocumentType and DataProfileAttrDefn (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 link is needed in order to require attribution based on DocumentType; which is the intent
Resolution:
Revised Text:
Actions taken:
October 3, 2010: received issue
Issue 15677: Navigability will dictated in the PIM. We must revisit the navigability of each association (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: This will determine the manner in which Sparx EA will traverse the UML graph to produce the XSD
Resolution:
Revised Text:
Actions taken:
October 3, 2010: received issue
Issue 15678: document.id type is “string”, it should be “ID”. (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: document.id type is “string”, it should be “ID”.
Resolution:
Revised Text:
Actions taken:
October 3, 2010: received issue
Discussion:
Issue 15685: No need for RecordCreator (rms-ftf)
Click here for this issue's archive.
Source: Everware-CBDI (Mr. John C. Butler, jbutler(at)everware-cbdi.com)
Nature: Uncategorized Issue
Severity:
Summary: Managed Record should just have an association to Party to show which party created the record.
Resolution:
Revised Text:
Actions taken:
October 5, 2010: received 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: