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: RE: [courtfiling-blue] A Modest Proposal


Overall your use of Part is similar to mine of MDE it is what the actor is interacting with. I do have a concern, though lessened now by the point in the project, which is that if you do not name the items below Submission, Review and Record they would not get the clarity of focus that they need.

 

Since we have done the analysis with the full set the danger is lower here. But, if we had used them as a starting point we would not be where we are now.

 

 

Regards,

Don

Donald L. Bergeron
Systems Designer
LexisNexis
donald.bergeron@lexisnexis.com
O 937-865-1276
H 937-748-2775
M 937-672-7781


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

 

It's time for...

 



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