RMS-FTF Issue Report

flipenergyΛογισμικό & κατασκευή λογ/κού

30 Οκτ 2013 (πριν από 3 χρόνια και 11 μήνες)

273 εμφανίσεις





RMS
-
FTF

Issue Report

Issue Log Version:

20101025
-
1056

Generated:
20101025
-
1056

Grouped by:




Ballot



Disposition


Filters:



Closed Items Excluded (including duplicates or merged issues)


RMS Issue Log

Table of Contents






Table of Contents


Ballot: None

................................
................................
................................
................................
...................
4

Disposition: Closed, No
Change

................................
................................
................................
................
4

Issue 15214: RMS would be better cast as a MOF model as opposed to a UML model.
......................
4

Disposition: Duplicate or Merged

................................
................................
................................
..............
7

Issue 15109: There are Errors in the RMS.XSD

................................
................................
....................
7

Disposition: None
................................
................................
................................
................................
.....
10

Issue 14030: Correct namespace URLs for the XSD and WSDL documents..

................................
...
10

Issue 14124: Exception Architecture

................................
................................
................................
...
11

Issue 14125: Need to add CRUD operations for RecordCreators
................................
........................
13

Issue 14126: Do we need additional Id's in CategoriesService and other places where ID’s are
missing?
................................
................................
................................
................................
................
14

Issue 14130: Add definition/discussion of "Record Schedule"

................................
...........................
16

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

................................
................................
................................
................................
.......................
18

Issue 14443: Optional document association for case file parts

................................
..........................
21

Issue 14444: Case file part refe
rence support

................................
................................
......................
23

Issue 14445: Cardinality on case file part definitions

................................
................................
..........
24

Issue 14969: Clarify that we are using the stereotypes from SOAML

................................
................
26

Issue 14970: Would a CaseFileDefinition, as core object in case management extend
CaseFileDefinition, or associate with it?
................................
................................
..............................
27

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

...
28

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

................................
....
29

Issue 14988: Content of RecordPart could be more

XML friendly

................................
.....................
31

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

................................
....
33

Issue 14997: Package Diagram is Incomplete
................................
................................
......................
34

Issue 15002: Specification of Attribute Sizes

................................
................................
......................
35

Issue 15021: We need to be able to add Annotations

to RecordPart’s as well as ManagedRecords

...
36

Issue 15022: Clarify the bi
-
directional relationships among documents, cases, and pa
rts

..................
37

Issue 15023: Explicit or implicit transaction model is needed.
................................
............................
38

Issue 15024: Need bundled operation requests

................................
................................
....................
40

Issue 15025:

We need to support management of a record in place.

................................
...................
41

Issue 15026: Assure minimum required attribution

................................
................................
.............
43

Issue 15108: CaseFilePart description is incorrect

................................
................................
..............
44

Issue 15211: We need a datum characteristic that indicates if it is systemAssigned.
..........................
46

Issue 15213: T
he RMS XMI is not well formed & does not play well with other tools

.....................
47

Issue 15226: There is no reference for RecordSet
Operations in the services

................................
.....
48

Issue 15229: The Spec does not define a schema for the query string
................................
.................
50

Disposition: None
................................
................................
................................
................................
.....
51

Issue 1523
0: Using plain Xquery can introduce security issues

................................
..........................
51

Issue 15671: Need convention to name referenced object via IDREF.

................................
...............
52

Issue 15672: Between DataProfileAttrDefn and AttributableClassType, the role names are
misleading.

................................
................................
................................
................................
...........
53

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

................................
................................
................................
................................
......................
54

RMS Issue Log

Table of Contents






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

................................
................................
................................
................................
................
55

Issue 15675: “Many” multiplicity is not accommodated by the XSD

................................
................
56

Issue 15676: There is no linkage

in the XSD between DocumentType and DataProfileAttrDefn.

.....
57

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

................................
................................
................................
................................
...........
58

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

................................
.............................
60

Issue 15685: No need for RecordCreator

................................
................................
.............................
61

Disposition: Resolved

................................
................................
................................
..............................
62

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

................................
................................
................................
..............
62

Issue 14442: Hierarchical composition of case file parts
................................
................................
.....
65

Issue 14967: Assurance of Document Integrity on Open

................................
................................
....
67

Issue 14968: We currently do not require any p
articular time or event that the authentication be done

................................
................................
................................
................................
..............................
69

Issue 14972: Double Delete Authority
................................
................................
................................
.
72

Issue 15000: Relationship of CaseFile "Close" and RecordSet "Cutoff" Operations.

.........................
74

Ballot: Ballot 1

................................
................................
................................
................................
.............
75

Disposition: Closed, no change

................................
................................
................................
................
75

Issue 14134: 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.

................................
................................
................................
................................
..........
75

Issue 14971: Are we missing a Repository Service?

................................
................................
...........
79

Issue 15228: ManagedRecord Clarification

................................
................................
.........................
81

Disposition: Closed, out of scope
................................
................................
................................
.............
83

Issue 14127: Need to finish UseCaseRealizations

Find Disposition Candidates Realization

...........
83

Issue 14128: Need to finish capt
uring the relationships between the Use Cases and the actors.

........
85

Issue 14129: Specification needs declaration of compatibility

................................
............................
87

Issue 14973: Need to provide formal description of behavior for operations.
................................
.....
89

Disposition: Resolved

................................
................................
................................
..............................
90

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

...................
90

Ballot: Ballot 2

................................
................................
................................
................................
.............
91

Disposition: None
................................
................................
................................
................................
.....
91

Issue 14132:

What happens on "destruction" or "transfer"

................................
................................
..
91

Issue 14999: Documents shared among CaseFile's and "vanilla" ManagedRecord's

..........................
94

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

................................
.............
124

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

..
126

Issue 15227: There are no services defined to capture or modify case files

................................
......
129

Disposition: Resolved

................................
................................
................................
............................
131

Issue 15114: RecordKeeper is related to ManagedRecord. Shouldn't it be to RecordSet?
................
131




Section 3
RMS
-
FTF

Issue Log







Ballot:
None

Disposition:
Closed, No Change

Issue 15214: RMS would be better cast as a MOF model as opposed to a UML
model.

Description:

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)

Sta
tus:
Votable

Priority:
1
-
High

Assigned To:
John Butler

Category:
Model

Related Issues:
15212

Discussion Notes:

20100914

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. We’ll work with Sam Mancarella of Sparx Systems to resolve the export issues to XMI.

20100517

Discussion of metamodel forms and the impact on exchange files:

EMOF is more constr
ained than CMOF



Neither EMOF or CMOF have association classes.



Neither CMOF or EMOF can have n
-
ary associations.



UML White diamond in MOF (C or E) is ignored. No problem with black diamond in either.



UML Association

o

CMOF



Identical to UML

o

EMOF



A pair of pro
perties each pointing to each class, ala foreign keys in a mutual link
relationship in RDB

Section 3
RMS
-
FTF

Issue Log









CMOF has association, but in EMOF it is a property which is typed as another class.

o

In CMOF you can choose whether to transform a UML association to a formal associa
tion, or
as a property ala EMOF



EMOF doesn't have constraints.



CMOF
-
> EMOF

o

What algorithm? are associations converted to another "pseudo" class, or implement simply as
a pair of properties between the class.



EMOF
-
> CMOF

o

Straight translation "generally".

In either containment is a property of the property that points to the contained elements via a Boolean.

Sparx uses ?... probably EMOF.

Eclipse uses EMOF which is a derivative ECore. (EMOF is an attempt to standardize ECore.



not much structural difference.



Eclipse tools can directly consume EMOF.



EMF is a component of Eclipse that does

o

consumes EMOF but not CMOF

20100401

In discussions with Sridhar Iyengar in the Jacksonville

meeting, it was suggested that we should use a
MOF model rather than a UML model. The lead RMS modelers (John Butler & Larry Johnson) are
primarily domain modelers; we will have to sort out the implications of that. We had hoped to never
become more than
cursorily knowledgeable in the MOF... it seems that all hope in that regard is lost.

Resolution:

None

Revised Text:
None

Raised By:
Larry Johnson

Date Entered:
20100401

Date Changed:
20100914

Disposition:
Closed, No Change

Disposition Note:
None

Ballot:
No
ne

Section 3
RMS
-
FTF

Issue Log







Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Disposition:
Duplicate or Merged

Issue 15109: There are Errors in the RMS.XSD

Description:

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 XS
D from the model

Status:
Closed

Priority:
1
-
High

Assigned To:
John Butler

Category:
XSD

Related Issues:
Circular namespace issue & 14030

Discussion Notes:

20101005

This issue merged into 15212

20100914

We need to talk to Sam Mancarella of Sparx Systems to see if the latest version of EA fixes this or to get
a transformation that fixes this.

Second bullet is fixed in the model by removing the local ID definition. Sam made a fix to the
transformation to

recognize these as “XS:ID”.


20100816

IDREF’s have a name space of “xsd:” whereas it should be “xs:”

20100225

The following changes produce clean XSDs. Although this is resolvable, we need to see if we can correct
the issues through model correction and r
e
-
generation.

Changes to RMS.XSD:



The xs:restriction on DispositionStatus has a base="xs:unspecified"

o

Should be base="xs:string"

o

We need to find out if we can get EA to correct this.



For id elements the type specified is local type="ID"

Section 3
RMS
-
FTF

Issue Log







o

Should be type=xs:I
D

o

We need to correct this in EA



The namespaces have problems. The RMS.xsd can't find the AttributeProfile XSD. And there is a
spurious import of a blank name space. Namespaces need to be consistent across both files. The
AttributeProfile.xsd needs to impor
t the RMS.xsd.

o

There is a import of a blank namespace



Remove the line.

o

Need to change:



<xs:schema targetNamespace="http://www.omg.org/spec/rms/20090327"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:rms="http://www.omg.org/spec/rms/20090327"
xmlns:ap="
http://www.omg.org/spec/rmsAttrbProfile/20090327">




<xs:import namespace=""/>




<xs:import
namespace="http://www.omg.org/spec/rmsAttrbProfile/20090327"/>

o

To:



<xs:schema targetNamespace="http://www.omg.org/spec/RMS/20090327"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:rms="http://www.omg.org/spec/RMS/20090327"
xmlns:ap="http://www.omg.org/spec/rmsAttrbProfile/20090327">




<xs:import
namespace="http://www.omg.org/spec/rmsAttrbProfile/20090327"
schemaLocation="D:/000sandbox
/attributeprofile.xsd"/>

AttributeProfile XSD Changes:



There is a declaration of TimeStamp which is not used anywhere.

o

Remove from model (two places in XSD... one as element, one as complexType.



Can't find rms:Party

o

add import of rms namespace with schemaL
ocation.



Name space issues

o

Change from:



<xs:schema xmlns:rms="http://www.omg.org/spec/rms/20090327"
xmlns:ap="http://www.omg.org/spec/rmsAttrbProfile/20090327"
targetNamespace="http://www.omg.org/spec/rmsAttrbProfile/20090327"
xmlns:xs="http://www.w3.org/2
001/XMLSchema">

o

To:



<xs:schema xmlns:rms="http://www.omg.org/spec/RMS/20090327"
xmlns:ap="http://www.omg.org/spec/rmsAttrbProfile/20090327"
Section 3
RMS
-
FTF

Issue Log







targetNamespace="http://www.omg.org/spec/rmsAttrbProfile/20090327"
xmlns:xs="http://www.w3.org/2001/XMLSchema">




<x
s:import namespace="http://www.omg.org/spec/RMS/20090327"
schemaLocation="D:/000sandbox/rms.xsd"/>

Resolution:

Merged into Issue 15212

Revised Text:
None

Raised By:
Larry Johnson

Date Entered:
20100225

Date Changed:
20101005

Disposition:
Duplicate or Merge
d

Disposition Note:
Merged into Issue 15212, “The transformation algorithm from UML to XSD is
inadequate for RMS purposes”

Ballot:
None

Date Closed:
20101005

Section 3
RMS
-
FTF

Issue Log







Disposition:
None

Issue 14030: Correct namespace URLs for the XSD and WSDL documents..

Description:

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


Status:
Open

Priority:
2
-
Normal

Assigned To:
Robert Lario

Category:
XSD

Related Issues:
Unspecified

Discussion Notes:

20100211

Issue assigned to Robert Lario

20091203

We need to work with
Tom Rutt on this issue.

Resolution:

None

Revised Text:
Unspecified

Raised By:
Tom Rutt

Date Entered:
20090707

Date Changed:
20100211

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 14124: Exception Architecture

Description:

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.

Status:
Open

Priority:
2
-
Normal

Assi
gned To:
Larry Johnson

Category:
Behavior

Related Issues:
Unspecified

Discussion Notes:

20100914

Still on hold awaiting resources. Changed to Priority 2

20090728

Entered on behalf of the JRMS. Originally #21raised by Larry Johnson.

20070426

After we have
established the messaging and structural conventions and techniques of sequence patterns
in our specification we need to address (using again the exemplar services) the exception handling
architecture of services.

80% of the processing time in an "average"

application is spent in exception handling (not to be confused
with system error handling, an exercise left for the implementer). The unexpected must be expected or our
system will not be practical.

Resolution:

None

Revised Text:
Unspecified

Raised By:
La
rry Johnson

Date Entered:
20070426

Date Changed:
20100914

Section 3
RMS
-
FTF

Issue Log







Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 14125: Need to add CRUD operations for RecordCreators

Description:

Package: RecordCreatorsService

Status:
Open

Priority:
2
-
Normal

Assigned To:
John Butler

Category:
Behavior

Related Issues:
Unspecified

Discussion Notes:

20090728

Entered on behalf or the JRMS. Originally #174 raised by John Butler

20080410

Issue pulled out of a model annotation

Resolution:

None

Revi
sed Text:
Unspecified

Raised By:
Larry Johnson

Date Entered:
20080410

Date Changed:
20090728

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 14126: Do we need additional Id's in CategoriesService and other places
where ID’s
are missing?

Description:

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 b
e 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.

Status:
Open

Priority:
2
-
Normal

Assigned To:
Larry Johnson

Category:
Semantic

Related Issues:
Unspecified

Discussion Notes:

20100816

This is a more general issue.

Also identified is the need to provide ID’s for DataProfile and DataProfileAttrDefn.

20090728

Entered on behalf or the JRMS. Originally #178 raised by John Butler

20080516



The names are basically mea
ningless within an RME, the important thing is the id.



However, when a record has been transferred the ID will be meaningless unless we include name space information such
as Agency Name and any qualifier within the agency (suborg, systemid, etc) that is r
esponsible for issuing the auto
-
generated id.

20080515

Ids covered in
JRMS
Issue 202

20080410

Issue pulled out of a model annotation

Resolution:

Section 3
RMS
-
FTF

Issue Log







None

Revised Text:
Unspecified

Raised By:
Larry Johnson

Date Entered:
20080410

Date Changed:
20090728

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 14130: Add definition/discussion of "Record Schedule"

Description:

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

Status:
Open

Priority:
3
-
Low

Assigned To:
Daryll Prescott

Category:
Miscellaneous

Related Issues:
Unspecified

Discussion Notes:

20100325

<BM> & <RS> will review the discussion thread against what's currently in the spec & will advise as to
what changes if any need to b
e made.

20100308 <LJ> Annotation

We had a proposed Resolution on this for conversion (or transference) to Revised Text. Is a revision
necessary and does the 20100304 Memo supersede or require changes to the proposed Resolution.

20100304 <DP> Memo

Add defin
ition/discussion of "Record Schedule"


The information contained in the resolution document provides the adequate information that should be
provided within the specification.

In addition to the four below the following additional information should be inc
luded.


An agency carrying out a records identification process, or implementing

records management should
consider the primary purpose is to first identify the records being received or created. Then, the records
can be categorized using the appropriate r
ecords schedule. It is the categorization of the record that
provides the record with its disposition. It can be that some organizations lump their records into
temporary and permanent without broadly understanding some of their temporary records may have
dispositions of 75 years or more. Therefore, it is correct for an organization to first determine record
category

then identifying their records are either

temporary or permanent.

1.

An approved record schedule comprises a record categorization schema, which
includes record
categories, and an approved disposition instructions for each category.

2.

Disposition instructions comprise an ordered set of actions that will be carried out on a set of records.
The records in the set are determined by a Cutoff.

Section 3
RMS
-
FTF

Issue Log







3.

A Dispos
itionRecordSet is an instance based on a DispositionInstruction that has begun to (or is
prepared to) execute for a particular set of records. It tracks the DispositionActions that have occurred
as well as the planned actions for the records in the set.

4.

When a record is captured, it is assigned to a Record Category. At that time the appropriate
Disposition Plan is determined for the record and it is added to that plan.

20090728

Entered on behalf of the JRMS... It is not clear that this issue resolution w
as implemented. The resolution
should be revisited in the context of the RMS
-
FTF. Originally raised in 20081222 JRMS Meeting.

Resolution:

20081222

An approved record schedule comprises a record categorization schema, which includes record categories,
and an approved disposition instructions for each category.

Disposition instructions comprise an ordered set of actions that will be carried out on a
set of records.
The records in the set are determined by a Cutoff.

A DispositionRecordSet is an instance based on a DispositionInstruction that has begun to (or is prepared
to) execute for a particular set of records. It tracks the DispositionActions tha
t have occurred as well as
the planned actions for the records in the set.

When a record is captured, it is assigned to a Record Category. At that time the appropriate Disposition
Plan is determined for the record and it is added to that plan.

Revised T
ext:
Unspecified

Raised By:
Larry Johnson

Date Entered:
20081222

Date Changed:
20100325

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







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

Description:

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.

Status:
Open

Priority:
2
-
Normal

Assigned To:
Bill Manago

Category:
Behavior

Rel
ated Issues:
Unspecified

Discussion Notes:

20100325

<RS> & <BM> will review the discussion thread against what’s currently in the spec & will advise as to
what changes if any need to be made.

On the table is the proposal to add a freezeOnDispositionSuspend

Boolean attribute.

20100306 <DP> Memo

From the document: <DP>
: Maybe this needs to be explicitly stated that all attributes cannot be
overwritten or deleted, but can be updated with a more current one, this would include “incorrect
information” or some such that indicates the previous information was improperly assi
gned to a particular
attribute


of course I would do that and use annotation to describe what was going on and why the
attribute was updated to reflect incorrect information was entered, of course there would be an authority
with this annotation.

COMMENT

on my comment. Maybe the resolution here is that a hold order (from any legitimate
authority) freezes the record and all its management attributes at that time.

The outcome or objective of
what I am going to type is that of staying away from making huge

r
epositories of

copies. That is, this
would allow for you not have to do that but wouldn't preclude you from doing. it.

RECOMMENDATION. If somehow the managed record could have

some type of

something
-
or
-
other
that would allow the

managed record

(case file)
to be continued to be managed but that

you could present
the record

as it existed at the time of the hold order this is what needs to happen. This would require over
-
riding business rules that allowed for the deletion of annotations, since the

chronicled o
nes

aren't affected
because those data are kept.


Other information currently in the document that I believe I address above.

Section 3
RMS
-
FTF

Issue Log







The other statement is that only those attributes explicitly designated by the organizations rules that apply
to annotations can
be allowed to not have a history for the annotation of the managed record. All other
attributes if populated, must be maintained.

Add: Case File Parts are either history kept or not according to the policy by the organization that creates,
maintains and ma
nages a case file. See ISSUE 12 for Use Cases for Case files.

20090728

Entered on behalf of the JRMS... It is not clear that this issue resolution was implemented. The resolution
should be revisited in the context of the RMS
-
FTF. Originally raised in 20070
621 JRMS Meeting.

20080513

The title is incorrect.

The correct resolution has been phrased. This needs to be worked into the submission

20080331

<LJ>: We need to work the wording of this for the submission, and see if there are implications to the
model.

2
0080313

<DP>
: Maybe this needs to be explicitly stated that all attributes cannot be overwritten or deleted, but can
be updated with a more current one, this would include “incorrect information” or some such that
indicates the previous information was improperly assi
gned to a particular attribute


of course I would do
that and use annotation to describe what was going on and why the attribute was updated to reflect
incorrect information was entered, of course there would be an authority with this annotation.

The oth
er statement is that only those attributes explicitly designated by the organizations rules that apply
to annotations can be allowed to not have a history for the annotation of the managed record. All other
attributes if populated, must be maintained.

Add:

Case File Parts are either history kept or not according to the policy by the organization that creates,
maintains and manages a case file. See ISSUE 12 for Use Cases for Case files.

20070621

This can be handled by adding to DispositionSuspend a "freeze"
attribute, and defining its operational
ramifications.

Resolution:

"Deletable Pats", Replaceable Parts", "Non
-
chronicled annotations", and "Non
-
Chronicled Attributes"
cannot be changed or deleted while a suspension is on the managed record.

Revised Text:
U
nspecified

Section 3
RMS
-
FTF

Issue Log







Raised By:
Larry Johnson

Date Entered:
20090728

Date Changed:
20100325

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 14443: Optional document association for case file parts

Description:

Case file parts are attributable. To express structured data, you
do
not always need an associated
document. It should be possible to explicitly mark a case file part as 'no document expected'.

Status:
Open

Priority:
2
-
Normal

Assigned To:
Larry Johnson

Cat
egory:
Semantic

Related Issues:
14445

Discussion Notes:

20100302

The discussion from 20100119 and 20100114, and 20100113 was moved to Issue 14445

20091210

FTF Meeting, Long Beach

The model already expresses this possibility, though for other reasons. No ch
ange is necessary. This Issue
can be considered resolved.

However, the FTF is interested in hearing the business case that spawned this issue. Larry will ask Henk
to provide business case and examples of the application of a documentless RecordPart. (A for
eign
concept to Records Managers, Archivists and Preservationists.

Resolution:

None

Revised Text:
Unspecified

Raised By:
Henk de Man

Date Entered:
20090930

Date Changed:
20100119

Disposition:
None

Disposition Note:
None

Section 3
RMS
-
FTF

Issue Log







Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue

14444: Case file part reference support

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.

Status:
Open

Priority:
2
-
Normal

Assigned To:
Larry
Johnson

Category:
Semantic

Related Issues:
14442

Discussion Notes:

None

Resolution:

None

Revised Text:
Unspecified

Raised By:
Henk de Man

Date Entered:
20090930

Date Changed:
20090930

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 14445: Cardinality on case file part definitions

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, wher
eby 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).

Status:
Open

Priority:
2
-
Normal

Assigned To:
Larry Johns
on

Category:
Semantic

Related Issues:
14443

Discussion Notes:

20100218

How do we represent the proposed solution in UML of a string specifying the multiplicity and relate it to
the multiplicity indicated on the model?

Add text to the association that the
multiplicity is to be found there as well.

Q: What does it mean to have a minimum that is non
-
zero? Can a case file be created without it?... if not,
when is it required to be there. In a similar example we have Booleans like "requiredForDisposition" on
Da
taProfileAttrDefn.

20100119

Chair's Note: In updating the log with the results of 20100114, I developed second thoughts about
transitioning this to Resolvable and returned the status to Open.

Although the suggested resolution strictly meets the stated issu
e it has constraint problems, I don't think it
meets the spirit of the issue for purposes of Case File Management.

As proposed in the last meeting the Boolean values are not independent. Although this could be handled
through constraints, it would be a clu
msy solution. My first knee
-
jerk reaction was to suggest that a single
attribute be defined with values implied by the Boolean variable names. That would resolve the
dependency issue.

But a different solution could provide considerable flexibility. We coul
d add a field to
CaseFilePartDefinition such as and CaseFilePartDocumentMultiplicity of type string constrained to the
usual multiplicity expressions "n..m", "n..*".

Section 3
RMS
-
FTF

Issue Log







Another useful construct would be to define CaseFilePartMultiplicity. This would permit th
e
CaseFileDefinition great flexibility in providing rules for the population of CaseFilePart's as well as their
associated Documents.

20100114

Add to CaseFilePartDefinition the following Booleans



CaseFileDocumentRequired



CaseFileDocumentOptional



CaseFile
DocumentDissallowed

20100113

In closing this issue in the log it became clear we missed something. The ability to mark the optionality in
the CaseFilePartDefinition. (LJ)

Resolution:

None

Revised Text:
Unspecified

Raised By:
Henk de Man

Date Entered:
20090
930

Date Changed:
20100218

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 14969: Clarify that we are using the stereotypes from SOAML

Description:

Clarify that we are using the stereotypes from SOAML (John Butler, 20090326)

Status:
Open

Priority:
3
-
Low

Assigned To:
John Butler

Category:
Model

Related Issues:
Unspecified

Discussion Notes:

None

Resolution:

None

Revised Text:
Unspecified

Raised By:
Unspecified

Date Entered:
Unspecified

Date Changed:
Unspecified

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 14970: Would a CaseFileDefinition, as core object in case management
extend CaseFileDefinition, or associate with it?

Description:

Would a C
aseDefinition, as core ob
ject in case management extend

C
aseFileD
efinition, or associate with
it
?

(Henk de Man, 20090225)

Status:
Open

Priority:
3
-
Low

Assigned To:
John Butler

Category:
Semantic

Related Issues:
Unspecified

Discussion Notes:

20100114

This issue will be dismissed as out of scope since it is
guidance for another RFP/Submission. However,
we will discuss it in this forum and advise another group of our opinion before dismissing. This should
probably be addressed by the Architecture Ecosystem SIG.

Resolution:

None

Revised Text:
Unspecified

Raised

By:
Unspecified

Date Entered:
Unspecified

Date Changed:
20100114

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







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

Description:

We n
eed to provide the capability to include/exclude records that are on hold for Disposition Candidates
identification.

(Bill Manago, 20091204)

Status:
Open

Priority:
2
-
Normal

Assigned To:
Bill Manago

Category:
Behavior

Related Issues:
Unspecified

Discussion
Notes:

None

Resolution:

None

Revised Text:
Unspecified

Raised By:
Unspecified

Date Entered:
Unspecified

Date Changed:
Unspecified

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







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

Description:

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.
0
2.
The 5015.
0
2 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 Presc
ott, 20091207)

Status:
Open

Priority:
2
-
Normal

Assigned To:
Bill Manago

Category:
Miscellaneous

Related Issues:
Unspecified

Discussion Notes:

20100305

During the discussion of Issue15000: "Relationship of CaseFile "Close" and RecordSet "Cutoff"
Operations"

it was pointed out that in customary records management practices "Cutoff" refers to a date
oriented event (either explicit date or determined by a periodic event, e.g. annually). This what it means in
both CA's CARM and in DoD 5015.02.

The concept of "Cu
toff" was generalized in RMS to accommodate the practices of diverse business
environments. It fully accommodates the above concepts of Cutoff. In RMS "Cutoff" signifies the
beginning of the DispositionPlan based on the DispositionInstruction template. (Th
e RecordSet can be
singleton if it is desired to "Cutoff" a single record, though that RecordSet must be attached to its own
DispositionPlan.

This underscores the need to work this issue to provide a mapping between the terminology of RMS and
other standar
ds. If we feel we need to change our terminology, we can do that.

<BM> will begin working this task in earnest and may add other domains as well (e.g., Moreq, etc.). This
work will serve as a precursor to defining AttributeProfile's for RMSv2.

Resolution:

Revised Text:
Unspecified

Raised By:
Daryll Prescott

Date Entered:
Unspecified

Section 3
RMS
-
FTF

Issue Log







Date Changed:
20100304

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 14988: Content of RecordPart could be more XML friendly

Description:

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 c
ontent 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 embe
dded 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 ty
pe "any" and then could store any arbitrary XML document.

Status:
Open

Priority:
3
-
Low

Assigned To:
Larry Johnson

Category:
Model

Related Issues:
Unspecified

Discussion Notes:

None

Resolution:

None

Revised Text:
Unspecified

Raised By:
Daniel Ruoso

Date Ent
ered:
20100120

Date Changed:
20100120

Disposition:
None

Disposition Note:
None

Ballot:
None

Section 3
RMS
-
FTF

Issue Log







Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







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

Description:

For the fields effectiveStartDate and effectiveEndDate i
n 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?

Status:
Open

Priority:
3
-
Low

Assigned To:
Larry Johnson

Category:
Semantic

Related Issues:
15026

Discussion
Notes:

None

Resolution:

None

Revised Text:
Unspecified

Raised By:
Daniel Ruoso

Date Entered:
20100120

Date Changed:
20100120

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 14997: Package Diagram is Incomplete

Description:

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

Status:
Open

Priority:
2
-
Normal

Assigned To:
John Butler

Category:
Model

Related Issues:
Unspecified

Discussion Notes:

None

Resolution:

None

Revis
ed Text:
Unspecified

Raised By:
Unspecified

Date Entered:
Unspecified

Date Changed:
Unspecified

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15002: Specification of Attribute Sizes

Description:

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?

Status:
Open

Priority:
2
-
Normal

Assigned To:
John Butler

Category:
Profiles

Related Issues:
Unspecified

Discussion Notes:

None

Resolution:

None

Revised Text:
Unspecified

Raised By:
Bill Manago

Date Entered:
20100121

Date Changed:
20100121

Disposition:
None

Disposi
tion Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







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

Description:

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 whic
h a Document is not classified, but in the presence of another
Document it is

Status:
Open

Priority:
2
-
Normal

Assigned To:
Larry Johnson

Category:
Semantic

Related Issues:
Unspecified

Discussion Notes:

20090917

Issue identified in RMS
-
FTF meeting during Sa
n Antonio TC meeting.

Resolution:

None

Revised Text:
Unspecified

Raised By:
RMS
-
FTF

Date Entered:
20100201

Date Changed:
20100201

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







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

Description:

Issue identified in the San Antonio TC RMS
-
FTF Meeting

Status:
Open

Priority:
3
-
Low

Assigned To:
John Butler

Category:
Semantic

Related Issues:
Unspecified

Discussion Notes:

20090917

Issue identified in
RMS
-
FTF meeting during San Antonio TC meeting.

Resolution:

None

Revised Text:
Unspecified

Raised By:
RMS
-
FTF

Date Entered:
20100201

Date Changed:
20100201

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15023: Explicit or impl
icit transaction model is needed.

Description:

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.

Status:
Open

Priority:
2
-
Normal

Assigned To:
Larr
y Johnson

Category:
Behavior

Related Issues:
Need bundled operation requests

Discussion Notes:

20100914

Changed from Priority 1 to 2

20100128

We can expose/create operations which on return are guaranteed to be fully complete or failed but leaving
the repo
sitory in its original state. Only those operations would be exposed to a client. A stated constraint
for t
he repository would be that each of these operations constitute a transaction and leave the transaction
management to the implementation. Or...

We can expose the concepts of rollback and commit to the client. The client would need to start a
transaction
and declare it done. If all the operations between the start and end satisfy the repository
constraints then the operations would be committed, el
se they would all be rolled back.

Resolution:

None

Revised Text:
Unspecified

Raised By:
RMS
-
FTF

Date Entered:
20100128

Date Changed:
20100914

Disposition:
None

Section 3
RMS
-
FTF

Issue Log







Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15024: Need bundled operation reques
ts

Description:

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 valu
es on an attributable object at one time, set
-
aside many records at a time.)

Status:
Open

Priority:
2
-
Normal

Assigned To:
John Butler

Category:
Model

Related Issues:
Explicit or implicit transaction model is needed.

Discussion Notes:

None

Resolution:

None

Revised Text:
Unspecified

Raised By:
RMS
-
FTF

Date Entered:
20100128

Date Changed:
20100202

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15025: We need to support management of a record in place.

Description:

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.

Status:
Open

Priority:
2
-
Normal

Assigned To:
Larry Johnson

Category:
Semantic

Related Issues:
14967

Discussion Notes:

20100128

We need a constraint that Document shall have at least one of content or location to support management
in place.

Location is currently stated to be logical rather than physical. And was intended to be a logical location
re
solvable by the server to physical location, but never specified by the client. We need the client to be
able to specify a physical location in order to manage in place. What does this do to our intent of
supporting a logical location that is resolved to o
ne or more physical locations by the infrastructure?

We may need a location specified by the client as to the source. This would be a physical file path, And
another location that could be an encoded representation only known to the environment that is use
d to
guide the system as to where the file is.

Resolution:

None

Revised Text:
Unspecified

Raised By:
RMS
-
FTF

Date Entered:
20100128

Date Changed:
20100202

Disposition:
None

Disposition Note:
None

Section 3
RMS
-
FTF

Issue Log







Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15026: Assure minimum
required attribution

Description:

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

Status:
Open

Priority:
2
-
Normal

Assigned To:
Larry Johnson

Category:
S
emantic

Related Issues:
14996

Discussion Notes:

20100128

We need to tabulate all attributes of all classes and assure that attributes are optional unless absolutely
necessary. It is not clear what feature in Sparx EA supports this.

Resolution:

None

Revised

Text:
Unspecified

Raised By:
RMS
-
FTF

Date Entered:
20100128

Date Changed:
20100202

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15108: CaseFilePart description is incorrect

Description:

The CaseFilePart description does no
t properly reference CaseFilePartDefinition concerning constraints
on the CaseFilePart

Status:
Open

Priority:
2
-
Normal

Assigned To:
Larry Johnson

Category:
Semantic

Related Issues:
Unspecified

Discussion Notes:

20100218

Revised Text Proposed.

Resolution:

Replace the CaseFilePart description text

Revised Text:

Replace the CaseFilePart description which reads:

"Associates Documents with a CaseFileRecord. The attributes of the CaseFilePart constrain what types of
actions can be taken against the Document tha
t is linked into the CaseFile.

"If CaseFilePart.chronicled is "True" then the prev/next relationship is used to keep the history. (If the
part is appendable, the old copy is maintained in the history and a new appended one is added as current.
Similarly i
f it is replaceable. When deleting a chronicled CaseFilePart all that are linked in the history are
deleted."

With the text
:

"Associates Documents with a CaseFileRecord with its optional document. The attributes of the
CaseFilePartDefinition constrain what

types of actions can be taken against the CaseFilePart and its
Document.

"If CaseFilePartDefinition.chronicled is "True" then the prev/next relationship is used to keep the history.
(If the part is appendable, the old copy is maintained in the history an
d a new appended one is added as
current. Similarly if it is replaceable. When deleting (after transfer or on destruction) a chronicled
CaseFilePart all that are linked in the chronicled history are deleted."

Section 3
RMS
-
FTF

Issue Log







Raised By:
Larry Johnson

Date Entered:
20100211
8

Date Changed:
20100218

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15211: We need a datum characteristic that indicates if it is
systemAssigned.

Description:

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

Status:
Open

Priority:
2
-
Normal

Assigned To:
Bill Manago

Category:
Profiles

Related Issues:
Unspecified

Discussion Notes:

20100325

Discussed making each systemAssigned as chronicled, but then backed away since this
could be
cumbersome in cases like lastOpened, lastAccessed, etc.

Resolution:

None

Revised Text:
Unspecified

Raised By:
Bill Manago

Date Entered:
20100325

Date Changed:
20100325

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







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

Description:

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 o
riginal 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.

Status:
Open

Priority:
1
-
High

Assigned To:
Larry Johnson

Category:
Model

Rela
ted Issues:
Other XSD Issues

Discussion Notes:

20100401

Among the difficulties encountered beyond the MPG model changes was that Sparx EA did not generate
valid XMI. By making roundtrips between EA and other tooling, the errors were found and the XMI was
h
and edited to cleanliness. (With a little more hand editing, Bob created an XMI which loads cleanly into
MagicDraw and Artisan as well as EA. This is the XMI currently in the spec. This problem may correct
itself since EA is participating in the XMI interc
hange working group.

Resolution:

None

Revised Text:
None

Raised By:
Larry Johnson

Date Entered:
20100401

Date Changed:
20100401

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15226: There is no reference for RecordSet
Operations in the services

Description:

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?

Status:
Open

Priority:
2
-
Normal

Assigned

To:
John Butler

Category:
Model

Related Issues:
Unspecified

Discussion Notes:

20100921

Records are added to the record set by knowing the record creation date and record category (for the
business activity that created the record) we can obtain the record set by accessing the Disposition
Instruction for that Record Category and looking up th
e Disposition Plan (instance of the Disposition
Instruction) with an Effective Date on or earlier than the record creation date and on or before the cutoff
date in the Disposition Plan.

We have to work out the sequence of calls that captures the record,

associates it with the Record Category
and adds it to the appropriate Record Set.

20100914

Changed to Priority 2

20100504

<LJ> Memo

We need to fix
this
. RecordSet's were defined after the services were partitioned. Originally the Category
and Disposition
areas were presumed pre
-
loaded, addressing only the "read" in the "CRUD" matrix... i.e.,
cRud... only the read was addressed. Clearly that does not work now that disposition is based on the
RecordSet rather than each ManagedRecord. (We realized at some poi
nt that "cutoff" and similar
disposition actions needed the RecordSet concept).


btw... the completion of the full CRUD matrix of RMS operations is a requirement planned for RMS
Version 3. See our roadmap at
http://gov.omg.org/

(click the "Roadmap" button)


Version 1 & 2 primarily address the "set
-
aside" side of operations, but
this

issue clearly falls into that
bailiwick.

Resolution:

Section 3
RMS
-
FTF

Issue Log







None

Revised Text:
None

Raised By:
John Olden
-
Stahl

Date Entered:
20100428

Date Changed:
20100914

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15229: The Spec does not define a schema for the query string

Description:

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.

Status:
Open

Priority:
2
-
Normal

Assigned To:
Larry Johnson

Category:
Query

Related Issues:
Unspecified

Discussion Notes:

20100504

<LJ> Memo

It is our
understanding that a query string formatted as an XQuery based on the RMS XSD is sent to the
server, and an XML document based on the XSD is returned with the elements that satisfy the criteria. We
may need to

clarify this, or this is wrong
.

Resolution:

None

Revised Text:
None

Raised By:
John Olden
-
Stahl

Date Entered:
20100428

Date Changed:
20100504

Disposition:
None

Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Disposition:
None


Issue 15230: Using
plain Xquery can introduce security issues

Description:

Using plain Xquery can introduce security issues when it comes to authentications and authorization.


Has
this approach been revised?

Status:
Open

Priority:
2
-
Normal

Assigned To:
Larry Johnson

Categor
y:
Query

Related Issues:
Unspecified

Discussion Notes:

None

Resolution:

None

Revised Text:
None

Raised By:
John Olden
-
Stahl

Date Entered:
20100428

Date Changed:
20100428

Disposition:
None


Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15671:
Need convention to name referenced object via IDREF.

Description:

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.

Status:
Open

Priority:
1
-
High

Assigned To:
John Butler

Category:
XSD

Related Issues:
15212

Discussion Notes:

None

Resolution:

None

Revised Text:
None

Raised By:
Larry Johnson

Date Entered:
20100816

Date Changed:
20100816

Disposition:
None


Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15672: Between DataProfileAttrDefn and AttributableClassType, the role
names are m
isleading.

Description:

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

Status:
Open

Priority:
2
-
Normal

Assigned To:
John Butler

Category:
XSD

Related Issues:
Unspecified

Discussion
Notes:

None

Resolution:

None

Revised Text:
None

Raised By:
RMS
-
FTF

Date Entered:
20100816

Date Changed:
20100816

Disposition:
None


Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







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

Description:

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.

Status:
Open

Priority:
2
-
Normal

Assigned To:
John Butler

Category:
XSD

Related Issues:
Unspecified

Discussion Notes:

20100902

W3C ID’s can have varying levels of uniqueness from a domain perspective. Primarily ID’s are
constrained to be unique within the document in which they occur. They are not designed to be

prime
globally unique identifiers per se.

We will need to specify our intent for global uniqueness.

Resolution:

None

Revised Text:
None

Raised By:
RMS
-
FTF

Date Entered:
20100816

Date Changed:
20100816

Disposition:
None


Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







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

Description:

We list a party ID as an attribute in the style of a foreign key in the PIM. Generally we explicitly model
association
s in the PIM. It would however remain a foreign key in the PSM XSD.

Status:
Open

Priority:
2
-
Normal

Assigned To:
John Butler

Category:
XSD

Related Issues:
Unspecified

Discussion Notes:

None

Resolution:

None

Revised Text:
None

Raised By:
RMS
-
FTF

Date Entere
d:
20100816

Date Changed:
20100816

Disposition:
None


Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15675: “Many” multiplicity is not accommodated by the XSD

Description:

For example, an AttributeClassType can have many DataProfileAttrDefn’s

(maxoccurs=”unbounded”,
which is the default).

Status:
Open

Priority:
2
-
Normal

Assigned To:
John Butler

Category:
XSD

Related Issues:
Unspecified

Discussion Notes:

None

Resolution:

None

Revised Text:
None

Raised By:
RMS
-
FTF

Date Entered:
20100816

Date Changed:
20100816

Disposition:
None


Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15676: There is no linkage in the XSD between DocumentType and
DataProfileAttrDefn.

Description:

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

Status:
Open

Priority:
2
-
Normal

Assigned To:
John Butler

Category:
XSD

Related Issues:
Unspecified

Discussion Notes:

None

Resolution:

None

Revised Text:
None

Raised By:
RMS
-
FTF

Date Entered:
20100816

Date Changed:
20100816

Disposition:
None


Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







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

Description:

This will determine the manner in which Sparx EA will t
raverse the UML graph to produce the XSD.

Status:
Open

Priority:
2
-
Normal

Assigned To:
John Butler

Category:
XSD

Related Issues:
15212

Discussion Notes:

20100831

Goals are to have an XSD that preserves associations via IDREF’s with correct multiplicity.

Current transform preserves the associations bi
-
directionality



Do we want the capability to constrain the directionality



If so, we will need to tag the PIM… the generated PSM already has both directions via IDREF foreign keys. To make it
one directional wo
uld require editing out the appropriate IDREF in the stereotyped model that is not desired. This would
be lost on the next generation of the PSM.



We therefore need to be able tag each relationship with the navigability. We could easily use the current UML
association
characteristic of navigability direction, but is it possible that it would be different depending on what the purpose of the
export it?



We could preserve bi
-
directionality as it is as far as the XSD goes while we provide a definition of the
navigability we
want (and what entities we wish to include)… perhaps via Xpath?... or Xquery?

Need to do a global change to types id:ID, dateTime & duration

Resolution:

None

Revised Text:
None

Raised By:
RMS
-
FTF

Date Entered:
20100816

Date Changed:
2010083
0

Disposition:
None


Disposition Note:
None

Section 3
RMS
-
FTF

Issue Log







Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







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

Description:

Self
-
explanatory.

Status:
Open

Priority:
2
-
Normal

Assigned To:
John Butler

Category:
XSD

Related Issues:
U
nspecified

Discussion Notes:

None

Resolution:

None

Revised Text:
None

Raised By:
RMS
-
FTF

Date Entered:
20100816

Date Changed:
20100816

Disposition:
None


Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Issue 15685: No need for RecordCreator

Description:

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

Status:
Open

Priority:
2
-
Normal

Assigned To:
Larry Johnson

Category:
Unspecified

Related Issues:
Unspecified

Discussion Notes:

None

Resolution:

None

Revised Text:
None

Raised By:
John Butler

Date Entered:
20101008

Date Changed:
20101008

Disposition:
None


Disposition Note:
None

Ballot:
None

Date Closed:
Open

Section 3
RMS
-
FTF

Issue Log







Disposition:
Resolved

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

Description:

None

Status:
Resolvable

Priority:
2
-
Normal

Assigned To:
Daryll Prescott

Category:
Semantic

Related Issues:
Unspecified

Discussion Notes:

20100421

Verified

20100311

Add that there shall
be one and only one AuthenticationMethod inForce at one time. inForce means use
this method for all newly set
-
aside records.

20100306 <DP> Memo

Commenting on 20100305

COMMENT: That is what I took "en force" to mean, that is the one currently being used. I
took the
others, the ones not "en force" as being valid because there were still records that had been authenticated
with it/them but had not been updated to use the "en force" authentication.


Perhaps some adjectives are
required.

Concerning process agnos
ticism:

COMMENT: Good records management requires a type of authentication or you are not really doing
records management you are doing document management. Let me provide a paper example. In the old
days, the records were centrally located and under the w
atchful eye of an adminsitrator who would be
responsible for locking the cabinet with the records at the end of the day. Some processes included
logging the cablinet open and closed, others inlcuded check out registers, but all were under the control of
so
mebody. This was because this was the authentication method that assured the records were complete,
have not been tampered with, and were not forgeries. This was not a nice to have, it was requried or there
was no way an attestation of the evidence they re
present could be made. Consideration for some type of
authentication should be made, this is parralell to the requrement that only a copy of a record be provided
on a request.

Section 3
RMS
-
FTF

Issue Log







20100305 <LJ> Memo

It seems that inForce is an over
-
loaded concept.


It means a
uthentication methods that are actually "active" methods, i.e. there are records whose
authentication is still based on that method. Perhaps we should change the name of the attribute to
something like "active"?


Is there buried in the inForce concept a "c
urrentlyUsed" authentication method, i.e., newly set
-
aside
records should be validated with this preferred, current method? Can there be more than one such
method? (My gut feeling is "No", but the question needs to be posed and answered... who would select

among the options and how?)


As to: "an authentication method be mandatory, at least one shall be en force at the time the document is
set aside as a record and the authentication be set at the immediate time of the set aside":


We have been meticulous i
n being business process agnostic in the RMS specification. It has almost been
a "prime directive" as a guiding principle. Although having an active and inForce authentication process
is good records management practice, I think it is outside the purview o
f the RMS to enforce good
practices. The RMS is intentionally minimalistic. "Best Practices" might be best left to a separate
document on the use of RMS rather than try to dictate those practices. "Best Practice" will evolve... the
RMS needs to accommodate

whatever they are. Further, such best practices may be quite different
depending on the business domain/milieu in which the records are being managed.

20100304 <DP> Memo

Two Questions

1.


How many In Force authentication methods can there be?

As many as
have been used, that is that if a record is associated with an authenticity

method and

the
authenticity method is "in force" for that record (or set as the case may be) then the that method must be
kept. This gets to the management of the records whereby

I

would expect the records manager would be
monitoring this and updating authenticity methods to keep them current and up with

best in practice, etc.,
etc.


So
-

if an authenticity method is associated with a managed record it must be kept until it is
super
seded. When an authenticity method is no longer associated with any managed records (or

sets) then
it can be discharged from being managed. The model supports this viewpoint.

2. Does there have to be at least one in force at all times?

Neither the model n
or the original functional requirements demand an authentication method be in force
at any time. HOWEVER, this should be reconsidered because how do you know the managed record
being managed after it is set as a managed record is in fact what it was when y
ou put it there. Without an
authentication method to apply to the record when it is set aside as a managed record you have an
unreliable environment for managing the record (sets).

THEREFORE I recommend an authentication method be mandatory, at least one s
hall be en force at the
time the document is set aside as a record and the authentication be set at the immediate time of the set
aside.

Section 3
RMS
-
FTF

Issue Log







200900728

Entered on behalf of the JRMS... Originally raised by John Butler