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

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 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 14133: How many In Force authentication methods can there be? Does there have to be at least one in force at all times?
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 14972: Double Delete Authority
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 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 15211: We need a datum characteristic that indicates if it is systemAssigned
Issue 15213: The RMS XMI is not well formed & does not play well with other tools
Issue 15226: There is no reference for Record Sets Operations in the services
Issue 15229: The Spec does not define a schema for the query string
Issue 15230: Using plain Xquery can introduce security issues
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 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]

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]

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]

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)

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)

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

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

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

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

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?

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.

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

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

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.

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.

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

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

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

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

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