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
- Home
- Browse
- All Categories
- AI and Robotics
- Biotechnology
- Clean Technology
- Data Management
- Electronics - Devices
- Enterprise Applications
- Entertainment
- Internet and Web Development
- Management
- Mechanics
- Mobile - Wireless
- Networking and Communications
- Oil and Offshore
- Security
- Semiconductor
- Servers
- Software and s/w Development
- Storage
- Telecommunications
- Urban and Civil
- Community
- Upload
Comments 0
Log in to post a comment