Next in thread → Next in month →

RE: [legalxml-courtfiling] Correct version of committee report on recent Durham recommendations

From
Christopher Durham
Date
2005-10-11T15:25:00+00:00
ID
Thread
RE: [legalxml-courtfiling] Correct version of committee report on recent Durham recommendations
MHonArc v2.5.0b2 -->
















legalxml-courtfiling message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: RE: [legalxml-courtfiling] Correct version of committee report on recent Durham recommendations




From: 
To: 
Date: Tue, 11 Oct 2005 08:30:53 -0700









The following statements in the latest review 
committee report are really at the heart of our 
discussions:
 
Rephrasing an earlier justification for why queries 
need to be defined in separate MDEs (one special MDE per query), the committee 
has said:

  >> so that implementers have the option of assigning queries to 
  different applications.
 
On the issue of whether the query to obtain a service list, 
exists as part of the CourtRecordMDE:

  >> many courts will not want to allow queries directly against 
  their operating data bases.  So, 
  we created a Service MDE with the function of handling this 
  query.
 
On the issue of whether the query to obtain policy exists 
as part of the FilingReviewMDE:

  >> By maintaining a separate Court Policy MDE we maintain the 
  maximum flexibility for implementers.  
  Some may choose your preferred course and combine the Court Policy and 
  Filing Review MDEs in the same 
application
 

I feel that all of these statements 
reflect a misunderstanding of the MDE concept.
 
In an earlier 
message, I tried to remind ourselves that how we categorize our functions into 
MDE, will not dictate or restrict how applications can be 
assembled.   
 
MDE is an organizational 
concept.  It does not define how a specific implementation must be 
created.
 
If, for example, we say that there is 
a conceptual thing we call CourtRecordMDE, and it includes such-n-such set 
of defined interactions, we still have not dictated any of 
this:
 
    (1) Which defined 
interactions must be implemented.
    (2) Which systems, and 
how many systems,  should host the interactions.
    (3) Which databases, 
and how many databases, are to be effected by the 
interactions.
 
A developer could choose to 
implement a 'CourtRecordMDE' by creating an application where every interaction 
is hosted on a separate system, each having its own physical 
database.   Or an implementer can choose to host a partial 
set of the interactions on one system, against one database.  
Or.. anything in between.
 
 
Applications can be assembled with 
any combination of MDE functions, across any number of physical 
systems,  interacting with any number of data 
sources.
 
Our decisions on how to organize 
the MDE should not be based upon any perceived implementation advantage 
of one approach vs another.  These is no implementation 
advantage.
 
 
I believe the committee's 
comments do not reflect that same understanding.
 
I further believe that the basis for 
the review committee's latest recommendations, taken to a logical conclusion, 
would entirely do away with the MDE concept.  In effect, the committee's 
recommended approach will lead to a flat list of interactions (one per 
MDE), without any conceptual or functional 
grouping. 
 
At this point, the issue on the table is whether we will continue 
with the MDE concept at all.
 
- 
Shane Durham
LexisNexis
 
 
 
 


From: John M. Greacen [mailto:]
Sent: Monday, October 10, 2005 11:10 PM
To: Electronic 
Court Filing Technical Committeee
Subject: [legalxml-courtfiling] 
Correct version of committee report on recent Durham 
recommendations




I attached an incomplete version of 
the committee report to my email containing the agenda for tomorrow’s call. 
 Here is the correct version.  I apologize for the 
confusion.

John 
M. Greacen
Greacen 
Associates, LLC
HCR 


505-289-2164
505-289-2163 
(fax)
505-780-1450 
(cell)














[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]
Next in thread → Next in month →