Re: [legalxml-courtfiling] RE: [legalxml-courtfiling-policy] Sdurham -RE: Final Call - Cour t Filing Policy Requirements

MHonArc v2.5.2 -->

legalxml-courtfiling message

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

--

[Date Index]
 | [Thread Index]
 | [Elist Home]

Subject: Re: [legalxml-courtfiling] RE: [legalxml-courtfiling-policy] Sdurham -RE: Final Call - Cour	t Filing Policy Requirements

From: Dallas Powell <>

To: , ,,

Date: Mon, 21 Oct 2002 18:20:17 -0600

Re: Court Policy 

 

Can a vendor say that they are conforming to Court 
Filing 1.1 and not implement Court Policy1.x?  If they can, then Court 
Policy has no bearing on me, but if they cannot then I would not 
support the current Court Policy Requirements doc.

 

Here are my comments

1)

---------

The Court Policy Requirements document 
says:

"Goals of Court Policy Interface
The overarching 
goal of the CPI is to reduce the need for human interaction between the courts 
and the persons and organizations that interact with them (i.e., electronic 
filers and electronic filing service providers). "

---------

 

I would suggest that an EFSP needs to know at the 
time the software is being developed what EFM they will support.  Each 
unique court policy will force new code to be developed.  Even if they are 
not unique, but interpreted differently they will require unique 
code.

 

This quoted paragraph suggests that the Court CPI 
will reduce the interaction of the developers who are creating the code for the 
EFM and EFSP.  I do not agree with this.  The developers will not be 
able to create code simply based on a Court Policy Interface.  I think 
there is some confusion between an API and a CPI.  They are not 
equivalent.  If you give a developer an API the chances are much greater 
that they can code to it because an API needs to have clearly 
defined inputs and results.  There is no over inclusion in an 
API.  The developer needs to know exactly what he wants to do, what call he 
must make, and what the call will return.  The CPI does not provide 
the clarity of input and response at this time.  The CPI provides for a 
discovery process not a programming interface.

 

For example, how does the court policy describe the 
difference between Washington's King Counties expectations vs. Utah's.  
King County embeds their lead documents and all their attachments in a 
single PDF document, Utah separates them out.  Utah allows case 
initiation, King does not.    Some courts want to allow case 
initiation for filings that do not require fees and other courts do not have 
that option.  

 

When a filing comes in to Utah, we need to know 
what each document represents.  If the case identifies five 
defendants then the court wants to see 5 summons for that case.

 

In addition, Utah is accepting, Word, WordPerfect, 
PDF, XML, and multiple types of lead documents and attachments, and King County 
only accepts PDF at present.

 

How does a court policy define what type of digital 
certificates should be used?  Or what Certificate Authority should the user 
purchase his certificates from?  Or what type of certificate, business or 
individual?

 

Each EFSP MUST know in advance what EFM they can 
support or code will not exist to support it.

2)

----------
The Court Policy Requirements 
document says:
"Goals of Court Policy Interface

......The interoperability of and use of court 
filing systems will fail due to the great variety, number, and divergence in 
rules and procedures among the many court jurisdictions, unless they are able to 
communicate their local policies through a standardized CPI. 
"
----------

 

Is this court policy REALLY answering the "unless" 
here?  What is really going to cause the failure?  I propose that the 
failure will be caused because the developer has to develop code to deal with 
every court's differences.  Whether the CPI tells the developer all the 
differences or not, does not change the failure point, and that is that the 
developer has to develop code for all the differences.  Each time a new 
court comes on-line, the developer has to go figure out what the differences are 
and create a module that can deal with the differences unless they are exactly 
like others that already exist.  The failure point is having to create code 
for all differences when all differences are not yet know to the 
developer.

 

A developer cannot develop code for something that 
is not clearly known.

 

When I first read the Court Policy Requirements, I 
thought, if I don't have to deal with this then it does not matter what they 
write.  However, if I have to deal with this, then my recommendation is 
that it needs to be scaled back  or modified in its purpose.

 

I propose that the CPI should be an intersect 
between the filer, the EFSP, and the Jurisdiction.  That means, the filer 
can find out if the EFSP he is thinking about using supports the courts 
that he wants to work with.  It allows the EFSP to point to a chart 
that identifies what Jurisdictions he supports because 
the Jurisdictions posted what EFM they have implemented.

 

So, without trying to destroy everything, I feel 
that I must at least give an example that can function as a beginning 
point.

 

This suggestion mixes the Conformance testing 
criteria and Interoperability Type testing.  I know that I am introducing a 
new concept with Interoperability Type testing and how that is separate from 
Conformance testing and I will have to give examples of this in another 
document.  But the basic concept is a grid table that allows a 
jurisdiction to identify what EFM they implemented, and it allows the EFSP to 
define what EFMs they support.  The grid is as such:

 

Interoperability Levels by Jurisdiction ( I will define interoperability 
types in another message, this one is too long already.)

  
  

     
    
      
UT / AZ / NV Interop Types

    
      
King County Interop Types

    
      
NJ / NY / MA interop Types

    
      
DC ...

    
      
? / ? / ?

  

     
    
      
1

    
      
2

    
      
3

    
      
4

    
      
1

    
      
2

    
      
3

    
      
4

    
      
5

     
     
     
     
     
     
     
     
     
     

  

    
      
Conformance 1

     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     

  

    
      
Conformance 2

     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     

  

    
      
Conformance 3

     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     

  

    
      
Conformance 4

     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     

There are a couple of implications that this exposes.  

  
It says that each court that wants to initiate e-filing has a 
  choice.  They can point to a previous test or they can force a new 
  one.  ( I really don't think that any court believes they can put up a 
  new policy that is different that all others and expect existing EFSP software 
  to work for them.  Unless they adopt an EFM that has gone 
  through an interoperability test they will not know if they conform or 
  not.)

  
It allows an EFSP and EFM vendor to clearly define what they are 
  supporting.  

  
It eliminates uncertainty for the courts.

  
It allows jurisdictions to group together and influence each other.

  
It is a natural process for vendors who desire to target a specific 
  market.

  
If a jurisdiction adopts a specific EFM they can point to a 
  chart that tells what EFSPs will support them without having to go through an 
  interoperability test themselves. 

 

Dallas