[legalxml-courtfiling] Of Policy

MHonArc v2.5.2 -->
















legalxml-courtfiling message






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

--

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








Subject: [legalxml-courtfiling] Of Policy




From: "Durham, Shane (LNG-CL)" <>
To: 
Date: Tue, 22 Oct 2002 11:50:04 -0700









I am still digesting some of the new concepts Dallas 
has offered. If I understand him correctly, I concur with his 
thoughts on how vendors will be developing interfaces with the court. 
The 'policy set', as generally envisioned, attempts to 
take on for more than we can express effectively... and far more than a vendor 
would attempt to auto-interpret.
 
The things that a filing vendor might dynamically 
interpret are things like 'code validation lists', 'schedule of fees', and, 
maybe, 'business hours'.  These are things that can change on a very 
frequent basis.
 
Things such as 'allows attachments', 'must use PDF or 
XML'...   these are items vendors will simply build/configure based 
upon verbal conversations with the court.  
 
There are all sorts of icky details associated with 
receiving and interpreting policy sets.  Just the process of policy 
exchange - the mere process of moving the policy from one system to another is 
full of issues: when and how often, is it push model or pull, what are the 
error codes for incomplete policies, inconsistent policies, contradictoary 
policies, corrupt policies..   what to do with filings that are in 
progress when a policy changes? (that one can be enourmously complex, depending 
on how you want to resolve it)
 
Here's another thought too...   what system 
will BUILD the policy set?  Don't forget - building policies 
are exceptionally challenging too.  How complex would such a system 
need to be so that a court user can EXPRESS its business rules... would the 
courts even BOTHER populating such a system with the hundreds and hundreds of 
detailed rules.... how much of that system's data content could 
be pulled from the CMS..... and, if it did pull content from the CMS, 
would it be via the CMS-API?  (uh-oh... scope-creep, 
scope-creep!).  It gets awfully messy when you think abou 
it.
 

As an example of how tough this policy project will be, 
consider this parallel:  
Which is more complicated, creating an XML file.. or 
creating an XML DTD/schema?  Which is more complicated, 
creating a Database record, or creating a Database?
 
Developing a 'thing' is always much easier than 
expressing the rules for 'thing'.
 
We have the same challenge in LegalXML: If 
CourtFiling was n-degrees of difficulty...  A new XML structure to 
entirely express ALL of the rules for CourtFiling... is n-times-x 
degrees difficult. (and, I might argue.. pointless... since existing 
technoligies such as DTD/schema do, effectively, much the same 
thing.)
 
 
Nobody wants to tackle such challenging stuff just 
so the court can say "we don't accept new-case filings".  I can build 
a switch in my system and flip it... 12 months from now.. when the court 
changes its mind.  In a very practical sense, I don't need a policy 
set to tell me this rule.  (less is more?)
 

I truly beleive that we are expect 
far too much from 'court policies'.  Let's cut it down to 
something a bit more reasonable.
 
For now, let's focus on the 
essentials:
Vendors *MAY* want (may need) semi-frequent 
updates to validation/fee lists...  but only if the risk and pain of 
filing rejection is very great.  Otherwise, I thnk they'll be content 
to construct filings with an out-of-date validation list and manuualy 
correct the validations when the very occasional filing is 
rejected.
 
That's my more-than-two-cents 
worth!
 
I realize that I am standing on a large stump 
with a bull-horn in hand.  I had better step down now. 
Thanks for listening.
- Shane
 
 
-----Original 
Message-----
From: Dallas Powell 
[mailto:]
Sent: Monday, October 21, 2002 5:20 
PM
To: ; ; 
; 

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



  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
   












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

--

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


  









Powered by eList eXpress LLC