Issue 15879: RecordKeepers and Suspensions Services no longer exist but their ports are in the specification and the XMI file Jira Issue RMS11-6
Issue 17355: Typo �subordintate� in 8.4.4. and Figure 8.5 and the XMI and XSD Jira Issue RMS11-1
Issue 17356: The XMI references several Sparx-specific PrimitiveTypes Jira Issue RMS11-2
Issue 17357: Many elements are in the XMI as primitive types which are not at all primitive Jira Issue RMS11-3
Issue 17358: In the XSD, references to other elements have been incorrectly typed as xs:NCName rather than xs:IDREF Jira Issue RMS11-4
Issue 17359: The XSD makes properties all lowercase as opposed to the camelcase from the PIM Jira Issue RMS11-5
Issue 15879: RecordKeepers and Suspensions Services no longer exist but their ports are in the specification and the XMI file (rms-rtf)
Click here for this issue's archive.
Source: Object Management Group (Mr. Larry L. Johnson, larry(at)omg.org)
Nature: Uncategorized Issue
Severity:
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
RecordKeepers and Suspensions Services no longer exist but their ports are in the specification and the XMI file
Typo �subordintate� in 8.4.4. and Figure 8.5 and the XMI and XSD
The XMI references several Sparx-specific PrimitiveTypes in packages EA_none_Types_Package and EA_PrimitiveTypes_Package
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.
In the XSD, references to other elements have been incorrectly typed as xs:NCName rather than xs:IDREF
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.