Issues for Mailing list of the Records Management Services (RMS) Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

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 14030: FTF needs to use the appropriate namespace URLs for the XML schemas and WSDL documents (rms-ftf)

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 

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]

Package: RecordCreatorsService

[JRMS Remaining Issue]

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]

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]

Package: RmsUseCases

[JRMS Remaining Issue]

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]

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

[JRMS Remaining Issue]

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]

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]

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]

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]

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. 

 

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'.

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.

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). 

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

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

Clarify that we are using the steriotypes from SOAML

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

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

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)

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

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

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

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)

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.

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?

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

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.

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.

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?

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.

Issue identified in the San Antonio TC RMS-FTF Meeting

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

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.)

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.

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

 

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

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

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

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

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?