I've hesitated to jump into this because
I am admittedly not as familiar with the technicalities as so many of you are.
However, it seemed to me that we are hung up over words that carry
connotations that cause problems. On one side (the "component" approach) the
implication is inherent that there is some sort of designed system or
architecture constituted by these components. We don't want to bias our
standard by inadvertently (or subconsciously) adopting design results. On the
other side (the "functional" approach) the implication is ... well, different
... I'm not sure I understand.
HOWEVER...
Why not rely on the tried-and-true,
familiar and simple word, PART? A "Part" does not imply what kind of "Part"
something is, just that it belongs to a whole from which it has been
identified as a piece. The Part could be an action, a component, a series of
actions, or a term for a jumble of things that, taken together, are well
described by the label given to that Part.
Further, why not put the three PARTS
into simpler terms? We've been talking about "filing assembly" and "Clerk
Review" and other terms that I've found hard to accept because, like other
words, they carry connotations that can cause more confusion than clarity. So,
I think we can do better by trying to simplify, and I hope my proposals below
help do that without doing damage to what the hard-working drafters of the
requirements and Use Cases have intended and accomplished so
far.
Here's what I've come up with, hoping it
can help us. I'm not wedded to it, so if there are good reasons not to go in
this direction, I won't hang on.
INSTEAD OF
"COMPONENTS" OR "FUNCTIONS" USE "PARTS"
and
SIMPLIFY THEIR TITLES
TO 1) SUBMISSION, 2) REVIEW, AND 3) RECORD
1)
Submission
Part
a.
This covers the concept of
"assembly" because you can't submit something if it hasn't been created and
assembled
b.
This covers the concept of
"delivery" because it isn't submitted until it is
delivered
c.
This avoids calling a "submission"
a "Filing" (which has bothered me) - leaving "Filing" to be the term
describing what the Clerk formally does after Review by accepting a submission
and adding it to the Record - or, if nothing else, avoiding a term (filing)
that has multiple meanings and connotations depending on who's asked ("docket"
is a similar word in that regard)
d.
I assume this is involved with
whatever kinds of queries or policies that are necessary in order to complete
this Part
2)
Review Part
a.
This includes receiving the
submission (that is, it has gotten "in the door" and was
"stamped")
b.
This covers all aspects of "Clerk
Review" - I think it is redundant to say "Clerk Review," since no one but the
Clerk reviews the items submitted for entry into the court case record -
getting away from thinking about people here
c.
This culminates in the submission's
"passing" or "failing" the Review
1.
a notice of rejection comes from
here upon a "fail" result, and the document doesn't make it into the
Record
2.
a forwarding of the submission for
entry into "The Record" (involving either or both of data and document
records/files) follows a "pass" (or a "didn't fail")
result
d.
I assume this is involved with
whatever kinds of queries or policies that are necessary in order to complete
this Part
3)
Record Part
a.
This includes the capturing of data
for whatever purposes in the "Case Management System
(CMS)"
b.
This includes the capturing of
"passed" documents as items that constitute the case "record" (the "case
file") - a "passed" document is added to the "Document Management System"
(which we have previously identified as one of many elements of a
CMS)
c.
The Record Part would include not
just receipt, indexing, and preservation of documents and information, but
also retrieval, access, privilege management, and confidentiality - everything
that happens with a submitted document (and its accompanying data) after it
has "passed" through all Review steps
d.
I assume this is involved with
whatever kinds of queries or policies that are necessary in order to complete
this Part
REGARDING APIs (thanks
to "Wikipedia" for finally giving me some explanatory material that helps me
grasp the meaning and significance of "API," which all the technical folks
know in their bones, but which has been hard for me to
grasp)
- These aren't so much
"Interfaces" among the Parts as they are points of "inter-actions"
("interface" sounds passive to me-just laying there looking at each
other-it's the actions that are of interest)
- There are actions
between/among the Parts at the "interface" points (where the Parts connect,
collide, or intersect)
- These, I'm guessing,
get fleshed out and specified to describe the range of actions that are
possible between the Parts when different results are
obtained:
- Example A: The
Submission Part interacts with the Review Part to obtain a result of
"pass" or "fail" (or "try again") - each triggers a set of actions - a
"pass" sends back an acknowledgement and forwards the submission to the
Record Part - a "fail" sends a failure notice, perhaps a fine and advice
on error correction, and does not forward anything to the Record
Part
- Example B: At the
interface point between the Review Part and the Record Part, some action
has to be possible that will get the "metadata" exchanged so the "passed
document" can be "indexed" as a Record (there are no "failed" documents in
the Record, by definition) and some action has to be taken to capture,
secure, "freeze," and manage access to each "passed"
document
I hope these ideas contribute to the
search for resolution. Perhaps "Part" can be the term we embrace in order to
move forward - if and only if using "Part" doesn't do some other damage that I
haven't perceived.
I'll be able to participate in at least
the first half of today's conference call, but may not be able to remain on
line after 2 pm Pacific time due to a pre-scheduled meeting.
Regards,
Roger
Roger
Winters
Programs and Projects
Manager
King
County
Department of Judicial
Administration
516
Third Avenue,
E-609 MS:
KCC-JA-0609
Seattle,
Washington
98104
V: (206) 296-7838 F: (206)
296-0906
roger.winters@metrokc.gov
It's
time for...