Records Management Service Avatar
  1. OMG Specification

Records Management Service — All Issues

  • Acronym: RMS
  • Issues Count: 69
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
RMS11-49 Need to provide formal description of behavior for operations RMS 1.0b1 open
RMS-56 The transformation algorithm from UML to XSD is inadequate for RMS purposes. RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-55 RecordKeeper is related to ManagedRecord. Shouldn't it be to RecordSet? RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-50 Documents shared among CaseFile's and "vanilla" ManagedRecord's RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-49 Need to provide formal description of behavior for operations RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-51 Relationship of CaseFile "Close" and RecordSet "Cutoff" Operations RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-48 Are we missing a Repository Service? RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-57 RMS would be better cast as a MOF model as opposed to a UML model RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-58 There are no services defined to capture or modify case files RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-54 Do we need a root to reach everything in the RMS.XSD RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-53 In the RMS.XSD we have circularity between the rms and ap namespace RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-52 There are Errors in the RMS.XSD RMS 1.0b1 RMS 1.0b2 Resolved closed
RMSF2-44 Service packages require operation definitions RMS 1.0b2 RMS 1.0 Resolved closed
RMSF2-43 Need convention to name referenced object via IDREF RMS 1.0b2 RMS 1.0 Resolved closed
RMSF2-45 RecordKeepers and Suspensions Services no longer exist but their ports are in the specification and the XMI file RMS 1.0b2 RMS 1.0 Resolved closed
RMS-47 RecordCreator and RecordKeeper must have Agency (or the top level organization) RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-46 What happens on "destruction" or "transfer" RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-43 Need to finish UseCaseRealizations –Find Disposition Candidates Realization RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-45 Specification needs declaration of compatibility RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-44 Need to finish capturing the relationships between the Use Cases and the actors RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS-59 managed record clarification RMS 1.0b1 RMS 1.0b2 Resolved closed
RMS11-28 The RMS XMI is not well formed & does not play well with other tools RMS 1.0b1 open
RMS11-29 We need a datum characteristic that indicates if it is systemAssigned RMS 1.0b1 open
RMS11-33 We need to support management of a record in place RMS 1.0b1 open
RMS11-31 Need bundled operation requests RMS 1.0b1 open
RMS11-25 Between DataProfileAttrDefn and AttributableClassType, the role names are misleading RMS 1.0b2 open
RMS11-26 Using plain Xquery can introduce security issues RMS 1.0b1 open
RMS11-35 Explicit or implicit transaction model is needed RMS 1.0b1 open
RMS11-24 The Spec does not define a schema for the query string RMS 1.0b1 open
RMS11-27 There is no reference for Record Sets Operations in the services RMS 1.0b1 open
RMS11-32 Assure minimum required attribution RMS 1.0b1 open
RMS11-34 Clarify the bi-directional relationships among documents, cases, and parts RMS 1.0b1 open
RMS11-30 CaseFilePart description is incorrect RMS 1.0b1 open
RMS11-41 No need for RecordCreator RMS 1.0b2 open
RMS11-42 Navigability will dictated in the PIM. We must revisit the navigability of each association RMS 1.0b2 open
RMS11-44 There is no linkage in the XSD between DocumentType and DataProfileAttrDefn RMS 1.0b2 open
RMS11-45 AttributeValue.partyID in the PIM should be an association… it would be a partyID in the PSM RMS 1.0b2 open
RMS11-46 Are W3C ID’s globally unique, or are there further qualifications we need to put on our ID’s RMS 1.0b2 open
RMS11-47 Many” multiplicity is not accommodated by the XSD RMS 1.0b2 open
RMS11-43 document.id type is “string”, it should be “ID”. RMS 1.0b2 open
RMS11-40 Cardinality on case file part definitions RMS 1.0b1 open
RMS11-14 Case file part reference support RMS 1.0b1 open
RMS11-20 Need to add CRUD operations for RecordCreators RMS 1.0b1 open
RMS11-23 Exception Architecture RMS 1.0b1 open
RMS11-19 We must state that a hold on record attributes must disallow changes or updates of any sort. RMS 1.0b1 open
RMS11-18 Add definition/discussion of "Record Schedule" RMS 1.0b1 open
RMS11-21 Do we need additional Id's in CategoriesService? RMS 1.0b1 open
RMS11-16 Hierarchical composition of case file parts RMS 1.0b1 open
RMS11-22 FTF needs to use the appropriate namespace URLs for the XML schemas and WSDL documents RMS 1.0b1 open
RMS11-17 How many In Force authentication methods can there be? Does there have to be at least one in force at all times? RMS 1.0b1 open
RMS11-15 Optional document association for case file parts RMS 1.0b1 open
RMS11-8 Content of RecordPart could be more XML friendly RMS 1.0b1 open
RMS11-10 Clarify use of terms that occur in both RMS and DoD 5015.02 RMS 1.0b1 open
RMS11-48 We need to be able to add Annotations to RecordPart’s as well as ManagedRecords RMS 1.0b1 open
RMS11-36 Specification of Attribute Sizes RMS 1.0b1 open
RMS11-9 Double Delete Authority RMS 1.0b1 open
RMS11-11 Would a caseDefinition, as core object in case management extend caseFileDefinition, or associate with it? RMS 1.0b1 open
RMS11-7 Are effective and end dates required fields in the Party model? RMS 1.0b1 open
RMS11-38 We currently do not require any particular time or event that the authentication be done RMS 1.0b1 open
RMS11-39 Assurance of Document Integrity on Open RMS 1.0b1 open
RMS11-13 Filter required for operation that identifies MR's that are candidates for disposition. RMS 1.0b1 open
RMS11-37 Package Diagram is Incomplete RMS 1.0b1 open
RMS11-12 Clarify that we are using the steriotypes from SOAML RMS 1.0b1 open
RMS11-6 RecordKeepers and Suspensions Services no longer exist but their ports are in the specification and the XMI file RMS 1.0b2 open
RMS11-5 The XSD makes properties all lowercase as opposed to the camelcase from the PIM RMS 1.0 open
RMS11-4 In the XSD, references to other elements have been incorrectly typed as xs:NCName rather than xs:IDREF RMS 1.0 open
RMS11-3 Many elements are in the XMI as primitive types which are not at all primitive RMS 1.0 open
RMS11-2 The XMI references several Sparx-specific PrimitiveTypes RMS 1.0 open
RMS11-1 Typo “subordintate” in 8.4.4. and Figure 8.5 and the XMI and XSD RMS 1.0 open

Issues Descriptions

Need to provide formal description of behavior for operations

  • Key: RMS11-49
  • Legacy Issue Number: 14974
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

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

  • Reported: RMS 1.0b1 — Thu, 14 Jan 2010 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:34 GMT

The transformation algorithm from UML to XSD is inadequate for RMS purposes.

  • Key: RMS-56
  • Legacy Issue Number: 15212
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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.

  • Reported: RMS 1.0b1 — Tue, 20 Apr 2010 04:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RecordKeeper is related to ManagedRecord. Shouldn't it be to RecordSet?

  • Key: RMS-55
  • Legacy Issue Number: 15114
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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?

  • Reported: RMS 1.0b1 — Thu, 4 Mar 2010 05:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Documents shared among CaseFile's and "vanilla" ManagedRecord's

  • Key: RMS-50
  • Legacy Issue Number: 14999
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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.

  • Reported: RMS 1.0b1 — Thu, 21 Jan 2010 05:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need to provide formal description of behavior for operations

  • Key: RMS-49
  • Legacy Issue Number: 14973
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

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

  • Reported: RMS 1.0b1 — Thu, 14 Jan 2010 05:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    Out of Scope
    Revised Text:
    None

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relationship of CaseFile "Close" and RecordSet "Cutoff" Operations

  • Key: RMS-51
  • Legacy Issue Number: 15000
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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.

  • Reported: RMS 1.0b1 — Thu, 21 Jan 2010 05:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Are we missing a Repository Service?

  • Key: RMS-48
  • Legacy Issue Number: 14971
  • Status: closed  
  • Source: Hewlett-Packard ( Bill Manago)
  • Summary:

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

  • Reported: RMS 1.0b1 — Thu, 14 Jan 2010 05:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RMS would be better cast as a MOF model as opposed to a UML model

  • Key: RMS-57
  • Legacy Issue Number: 15214
  • Status: closed  
  • Source: International Business Machines ( Mr. Sridhar Iyengar)
  • 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)

  • Reported: RMS 1.0b1 — Tue, 20 Apr 2010 04:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There are no services defined to capture or modify case files

  • Key: RMS-58
  • Legacy Issue Number: 15227
  • Status: closed  
  • Source: Lockheed Martin ( John Olden-Stahl)
  • Summary:

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

  • Reported: RMS 1.0b1 — Fri, 23 Apr 2010 04:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    The requisite services are to be added

  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: RMS-54
  • Legacy Issue Number: 15111
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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

  • Reported: RMS 1.0b1 — Tue, 2 Mar 2010 05:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In the RMS.XSD we have circularity between the rms and ap namespace

  • Key: RMS-53
  • Legacy Issue Number: 15110
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

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

  • Reported: RMS 1.0b1 — Tue, 2 Mar 2010 05:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There are Errors in the RMS.XSD

  • Key: RMS-52
  • Legacy Issue Number: 15109
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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

  • Reported: RMS 1.0b1 — Tue, 2 Mar 2010 05:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    Merged into Issue 15212

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Service packages require operation definitions

  • Key: RMSF2-44
  • Legacy Issue Number: 15782
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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

  • Reported: RMS 1.0b2 — Tue, 26 Oct 2010 04:00 GMT
  • Disposition: Resolved — RMS 1.0
  • Disposition Summary:

    Operation definitions have been added

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need convention to name referenced object via IDREF

  • Key: RMSF2-43
  • Legacy Issue Number: 15671
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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

  • Reported: RMS 1.0b2 — Sun, 3 Oct 2010 04:00 GMT
  • Disposition: Resolved — RMS 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RecordKeepers and Suspensions Services no longer exist but their ports are in the specification and the XMI file

  • Key: RMSF2-45
  • Legacy Issue Number: 15871
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

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

  • Reported: RMS 1.0b2 — Tue, 7 Dec 2010 05:00 GMT
  • Disposition: Resolved — RMS 1.0
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RecordCreator and RecordKeeper must have Agency (or the top level organization)

  • Key: RMS-47
  • Legacy Issue Number: 14134
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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]

  • Reported: RMS 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What happens on "destruction" or "transfer"

  • Key: RMS-46
  • Legacy Issue Number: 14132
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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]

  • Reported: RMS 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need to finish UseCaseRealizations –Find Disposition Candidates Realization

  • Key: RMS-43
  • Legacy Issue Number: 14127
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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]

  • Reported: RMS 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    Out of Scope
    Revised Text:
    None

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification needs declaration of compatibility

  • Key: RMS-45
  • Legacy Issue Number: 14129
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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]

  • Reported: RMS 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    Out of Scope
    Revised Text:
    None

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need to finish capturing the relationships between the Use Cases and the actors

  • Key: RMS-44
  • Legacy Issue Number: 14128
  • Status: closed  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    Package: RmsUseCases

    [JRMS Remaining Issue]

  • Reported: RMS 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    Out of Scope
    Revised Text:
    None

  • Updated: Fri, 6 Mar 2015 20:58 GMT

managed record clarification

  • Key: RMS-59
  • Legacy Issue Number: 15228
  • Status: closed  
  • Source: Lockheed Martin ( John Olden-Stahl)
  • 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?

  • Reported: RMS 1.0b1 — Fri, 23 Apr 2010 04:00 GMT
  • Disposition: Resolved — RMS 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The RMS XMI is not well formed & does not play well with other tools

  • Key: RMS11-28
  • Legacy Issue Number: 15213
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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

  • Reported: RMS 1.0b1 — Tue, 20 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

We need a datum characteristic that indicates if it is systemAssigned

  • Key: RMS11-29
  • Legacy Issue Number: 15211
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    For AttributeProfiles it is important to distinguish between user entered and system entered fields.

  • Reported: RMS 1.0b1 — Tue, 20 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

We need to support management of a record in place

  • Key: RMS11-33
  • Legacy Issue Number: 15025
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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.

  • Reported: RMS 1.0b1 — Tue, 2 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need bundled operation requests

  • Key: RMS11-31
  • Legacy Issue Number: 15024
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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.)

  • Reported: RMS 1.0b1 — Tue, 2 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Between DataProfileAttrDefn and AttributableClassType, the role names are misleading

  • Key: RMS11-25
  • Legacy Issue Number: 15672
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    For example “type” should be “attributableClassType”; all the “definition” (4 of them) should be “attributeDefinition

  • Reported: RMS 1.0b2 — Sun, 3 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Using plain Xquery can introduce security issues

  • Key: RMS11-26
  • Legacy Issue Number: 15230
  • Status: open  
  • Source: Lockheed Martin ( John Olden-Stahl)
  • Summary:

    Using plain Xquery can introduce security issues when it comes to authentications and authorization. Has this approach been revised?

  • Reported: RMS 1.0b1 — Fri, 23 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Explicit or implicit transaction model is needed

  • Key: RMS11-35
  • Legacy Issue Number: 15023
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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

  • Reported: RMS 1.0b1 — Tue, 2 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The Spec does not define a schema for the query string

  • Key: RMS11-24
  • Legacy Issue Number: 15229
  • Status: open  
  • Source: Lockheed Martin ( John Olden-Stahl)
  • 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.

  • Reported: RMS 1.0b1 — Fri, 23 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

There is no reference for Record Sets Operations in the services

  • Key: RMS11-27
  • Legacy Issue Number: 15226
  • Status: open  
  • Source: Lockheed Martin ( John Olden-Stahl)
  • 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?

  • Reported: RMS 1.0b1 — Fri, 23 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Assure minimum required attribution

  • Key: RMS11-32
  • Legacy Issue Number: 15026
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    To fit the broadest spectrum of business processes we need to assure that only the absolutely necessary attributes for records management are required.

  • Reported: RMS 1.0b1 — Tue, 2 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarify the bi-directional relationships among documents, cases, and parts

  • Key: RMS11-34
  • Legacy Issue Number: 15022
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    Issue identified in the San Antonio TC RMS-FTF Meeting

  • Reported: RMS 1.0b1 — Mon, 1 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CaseFilePart description is incorrect

  • Key: RMS11-30
  • Legacy Issue Number: 15108
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    The CaseFilePart description does not properly reference CaseFilePartDefinition concerning constraints on the CaseFilePart

  • Reported: RMS 1.0b1 — Tue, 2 Mar 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No need for RecordCreator

  • Key: RMS11-41
  • Legacy Issue Number: 15685
  • Status: open  
  • Source: Auxilium Technology Group ( John Butler [X] (Inactive))
  • Summary:

    Managed Record should just have an association to Party to show which party created the record.

  • Reported: RMS 1.0b2 — Tue, 5 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Navigability will dictated in the PIM. We must revisit the navigability of each association

  • Key: RMS11-42
  • Legacy Issue Number: 15677
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    This will determine the manner in which Sparx EA will traverse the UML graph to produce the XSD

  • Reported: RMS 1.0b2 — Sun, 3 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

There is no linkage in the XSD between DocumentType and DataProfileAttrDefn

  • Key: RMS11-44
  • Legacy Issue Number: 15676
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    The link is needed in order to require attribution based on DocumentType; which is the intent

  • Reported: RMS 1.0b2 — Sun, 3 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

AttributeValue.partyID in the PIM should be an association… it would be a partyID in the PSM

  • Key: RMS11-45
  • Legacy Issue Number: 15674
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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.

  • Reported: RMS 1.0b2 — Sun, 3 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Are W3C ID’s globally unique, or are there further qualifications we need to put on our ID’s

  • Key: RMS11-46
  • Legacy Issue Number: 15673
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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.

  • Reported: RMS 1.0b2 — Sun, 3 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Many” multiplicity is not accommodated by the XSD

  • Key: RMS11-47
  • Legacy Issue Number: 15675
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    For example, an AttributeClassType can have many DataProfileAttrDefn’s (maxoccurs=”unbounded”, which is the default).

  • Reported: RMS 1.0b2 — Sun, 3 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

document.id type is “string”, it should be “ID”.

  • Key: RMS11-43
  • Legacy Issue Number: 15678
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    document.id type is “string”, it should be “ID”.

  • Reported: RMS 1.0b2 — Sun, 3 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cardinality on case file part definitions

  • Key: RMS11-40
  • Legacy Issue Number: 14445
  • Status: open  
  • Source: VDMbee ( Mr. Henk de Man)
  • 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).

  • Reported: RMS 1.0b1 — Mon, 28 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Case file part reference support

  • Key: RMS11-14
  • Legacy Issue Number: 14444
  • Status: open  
  • Source: VDMbee ( Mr. Henk de Man)
  • 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.

  • Reported: RMS 1.0b1 — Mon, 28 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need to add CRUD operations for RecordCreators

  • Key: RMS11-20
  • Legacy Issue Number: 14125
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    Package: RecordCreatorsService

    [JRMS Remaining Issue]

  • Reported: RMS 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exception Architecture

  • Key: RMS11-23
  • Legacy Issue Number: 14124
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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]

  • Reported: RMS 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

We must state that a hold on record attributes must disallow changes or updates of any sort.

  • Key: RMS11-19
  • Legacy Issue Number: 14131
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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]

  • Reported: RMS 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add definition/discussion of "Record Schedule"

  • Key: RMS11-18
  • Legacy Issue Number: 14130
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    The current discussion of Record Schedule and its relationship to categories is inadequate.

    [JRMS Remaining Issue]

  • Reported: RMS 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Do we need additional Id's in CategoriesService?

  • Key: RMS11-21
  • Legacy Issue Number: 14126
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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]

  • Reported: RMS 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Hierarchical composition of case file parts

  • Key: RMS11-16
  • Legacy Issue Number: 14442
  • Status: open  
  • Source: VDMbee ( Mr. Henk de Man)
  • 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.

  • Reported: RMS 1.0b1 — Mon, 28 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

FTF needs to use the appropriate namespace URLs for the XML schemas and WSDL documents

  • Key: RMS11-22
  • Legacy Issue Number: 14030
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • 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

  • Reported: RMS 1.0b1 — Wed, 24 Jun 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

How many In Force authentication methods can there be? Does there have to be at least one in force at all times?

  • Key: RMS11-17
  • Legacy Issue Number: 14133
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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]

  • Reported: RMS 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Optional document association for case file parts

  • Key: RMS11-15
  • Legacy Issue Number: 14443
  • Status: open  
  • Source: VDMbee ( Mr. Henk de Man)
  • 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'.

  • Reported: RMS 1.0b1 — Mon, 28 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Content of RecordPart could be more XML friendly

  • Key: RMS11-8
  • Legacy Issue Number: 14988
  • Status: open  
  • Source: Prefeitura de Fortaleza ( Daniel Ruoso)
  • 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.

  • Reported: RMS 1.0b1 — Tue, 19 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarify use of terms that occur in both RMS and DoD 5015.02

  • Key: RMS11-10
  • Legacy Issue Number: 14976
  • Status: open  
  • Source: TethersEnd Consulting ( Mr. Daryll Prescott)
  • 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)

  • Reported: RMS 1.0b1 — Thu, 14 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

We need to be able to add Annotations to RecordPart’s as well as ManagedRecords

  • Key: RMS11-48
  • Legacy Issue Number: 15021
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • 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.

  • Reported: RMS 1.0b1 — Mon, 1 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Specification of Attribute Sizes

  • Key: RMS11-36
  • Legacy Issue Number: 15002
  • Status: open  
  • Source: Hewlett-Packard ( Bill Manago)
  • 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?

  • Reported: RMS 1.0b1 — Fri, 22 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Double Delete Authority

  • Key: RMS11-9
  • Legacy Issue Number: 14972
  • Status: open  
  • Source: TethersEnd Consulting ( Mr. Daryll Prescott)
  • 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)

  • Reported: RMS 1.0b1 — Thu, 14 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Would a caseDefinition, as core object in case management extend caseFileDefinition, or associate with it?

  • Key: RMS11-11
  • Legacy Issue Number: 14970
  • Status: open  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Would a caseDefinition, as core object in case management extend caseFileDefinition, or associate with it? (Henk de Man, 20090225)

  • Reported: RMS 1.0b1 — Thu, 14 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Are effective and end dates required fields in the Party model?

  • Key: RMS11-7
  • Legacy Issue Number: 14996
  • Status: open  
  • Source: Prefeitura de Fortaleza ( Daniel Ruoso)
  • 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?

  • Reported: RMS 1.0b1 — Wed, 20 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

We currently do not require any particular time or event that the authentication be done

  • Key: RMS11-38
  • Legacy Issue Number: 14968
  • Status: open  
  • Source: TethersEnd Consulting ( Mr. Daryll Prescott)
  • 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

  • Reported: RMS 1.0b1 — Thu, 14 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Assurance of Document Integrity on Open

  • Key: RMS11-39
  • Legacy Issue Number: 14967
  • Status: open  
  • Source: TethersEnd Consulting ( Mr. Daryll Prescott)
  • 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

  • Reported: RMS 1.0b1 — Thu, 14 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Filter required for operation that identifies MR's that are candidates for disposition.

  • Key: RMS11-13
  • Legacy Issue Number: 14975
  • Status: open  
  • Source: Hewlett-Packard ( Bill Manago)
  • Summary:

    We need to provide the capability to include/exclude records that are on hold for Disposition Candidates identification. (Bill Manago, 20091204)

  • Reported: RMS 1.0b1 — Thu, 14 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Package Diagram is Incomplete

  • Key: RMS11-37
  • Legacy Issue Number: 14997
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    In the specification the package diagram does not include, for example, "Disposition". (Larry Johnson, 20091209

  • Reported: RMS 1.0b1 — Wed, 20 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarify that we are using the steriotypes from SOAML

  • Key: RMS11-12
  • Legacy Issue Number: 14969
  • Status: open  
  • Source: Auxilium Technology Group ( John Butler [X] (Inactive))
  • Summary:

    Clarify that we are using the steriotypes from SOAML

  • Reported: RMS 1.0b1 — Thu, 14 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

RecordKeepers and Suspensions Services no longer exist but their ports are in the specification and the XMI file

  • Key: RMS11-6
  • Legacy Issue Number: 15879
  • Status: open  
  • Source: Object Management Group ( Larry Johnson [X] (Inactive))
  • Summary:

    Title: RecordKeepers and Suspensions Services no longer exist but their ports are in the specification and the XMI file.

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

    RMS-FTF: We have the solution for the issue (discovered in Monday’s AB Meeting) and will apply it. A ballot will be issued as soon as we verify that we have clean XMI, and again, I will be asking for a quick turnaround. We need to have this fixed to go through the AB on Thursday

  • Reported: RMS 1.0b2 — Tue, 7 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The XSD makes properties all lowercase as opposed to the camelcase from the PIM

  • Key: RMS11-5
  • Legacy Issue Number: 17359
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The XSD makes properties all lowercase as opposed to the camelcase from the PIM, which makes them a lot less legible and inconsistent with normal XML Schema practice and inconsistent with the names generated for ids. For example effectiveStartDate becomes effectivestartdate. But we also have hasRoleID which is camelcase.

  • Reported: RMS 1.0 — Fri, 4 May 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

In the XSD, references to other elements have been incorrectly typed as xs:NCName rather than xs:IDREF

  • Key: RMS11-4
  • Legacy Issue Number: 17358
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In the XSD, references to other elements have been incorrectly typed as xs:NCName rather than xs:IDREF

  • Reported: RMS 1.0 — Fri, 4 May 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Many elements are in the XMI as primitive types which are not at all primitive

  • Key: RMS11-3
  • Legacy Issue Number: 17357
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Many elements are in the XMI as primitive types which are not at all primitive, for example RecordKeeper, ManagedRecord, PartyRoles[], Party[], SuspensionRevocationMethod, AuthenticationMethod, ActionEventSpecification, DispositionSuspend, Revocation. Some of these (e.g. DispositionSuspend) have both a class and a primitive type. I suspect this is because they have been used in operation parameters.

  • Reported: RMS 1.0 — Fri, 4 May 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The XMI references several Sparx-specific PrimitiveTypes

  • Key: RMS11-2
  • Legacy Issue Number: 17356
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The XMI references several Sparx-specific PrimitiveTypes in packages EA_none_Types_Package and EA_PrimitiveTypes_Package

  • Reported: RMS 1.0 — Fri, 4 May 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typo “subordintate” in 8.4.4. and Figure 8.5 and the XMI and XSD

  • Key: RMS11-1
  • Legacy Issue Number: 17355
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Typo “subordintate” in 8.4.4. and Figure 8.5 and the XMI and XSD

  • Reported: RMS 1.0 — Fri, 4 May 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT