OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

courtfiling-blue message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: [courtfiling-blue] A Modest Proposal




-----Original Message-----
From: Scott Came [mailto:scott@justiceintegration.com] 
Sent: Wednesday, March 02, 2005 1:26 PM
To: Clarke, Tom
Subject: Fw: [courtfiling-blue] A Modest Proposal

Tom, I'm not able to post to the list from my blackberry.  Would you
mind forwarding this for me?

Thanks.
--Scott
-----Original Message-----
From: "Scott Came" <scottcame@tmo.blackberry.net>
Date: Wed, 2 Mar 2005 21:23:42 
To:"Cusick, James"
<James.Cusick@wkglobal.com>;courtfiling-blue@lists.oasis-open.org
Subject: Re: [courtfiling-blue] A Modest Proposal

If you consider an "e-filing system" to be everything between the human
filer, on the one hand, and persistent data at the court, on the other,
then there are not just interfaces into that "system", but interfaces
within it as well.  We do not want to force "systems" in this sense to
be purchased from single vendors, or otherwise to be implemented
monolithically...do we?

The current components or mdes are our attempt to segment the "system"
into units that we wish, by the spec, to be interoperable.
-----Original Message-----
From: "Cusick, James" <James.Cusick@wkglobal.com>
Date: Wed, 2 Mar 2005 14:05:43 
To:"Winters, Roger" <Roger.Winters@METROKC.GOV>,
<courtfiling-blue@lists.oasis-open.org>
Subject: RE: [courtfiling-blue] A Modest Proposal

Roger, 
 
This is a set of useful suggestions. However, I think my point is being
lost in the "component" vs "non-component" discussion. What I am really
saying is that the philosophy of the Blue standard should be to define
the capabilities and interfaces to those capabilities provided by a
generic court e-filing system. There is no need to discuss components,
parts, entities, or anything else below the level of the system and its
interfaces. I do not think we should be standardizing on "components" by
any name. If I am mistaken in this understanding I apologize. 
 
Regards, 
james 
 
   
     From: Winters, Roger   [mailto:Roger.Winters@METROKC.GOV] 
Sent: Wednesday, March 02, 2005   11:55 AM
To:   'courtfiling-blue@lists.oasis-open.org'
Subject: [courtfiling-blue]   A Modest Proposal

   
   
   
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
   
<SPAN   style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: 
Sent wirelessly via BlackBerry from T-Mobile.
Sent wirelessly via BlackBerry from T-Mobile.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]