[legalxml-courtfiling-policy] Re: [legalxml-courtfiling] Of Policy

[John Messing <jmessing@law-on-line.com>]

A little history may help. In the paper world, courts look to a hierarchy of authoritative sources, such as constitutions, statutes, rules of court for the jurisdiction, and somewhat lower down, the local rules of the court. The local rules tell lawyers details about what the court expects with regard to a variety of matters, including formats and layouts for court filings. Court policy XML was supposed to transition local rules for efiling to the online environment.

I think what we are discovering is that the concept is not very portable from paper to electronics because of the complexities that accompany a many-to-many efiling delivery system such as the LegalXML family of standards contemplates.

That may require courts to retain local rules as text, and turn court policy into a web service that transmits standardized parameters to the infomediaries (EFSP's) that deliver the data.

I think the idea of scaling CP  down is probably wise.

---------- Original Message ----------------------------------
From: "Durham, Shane (LNG-CL)" <Shane.Durham@lexisnexis.com>
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:dpowell@tybera.com]
>Sent: Monday, October 21, 2002 5:20 PM
>To: Tom.Clarke@courts.wa.gov; Shane.Durham@lexisnexis.com;
>legalxml-courtfiling@lists.oasis-open.org;
>legalxml-courtfiling-policy@lists.oasis-open.org
>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.  
>
>1.	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.) 
>
>2.	It allows an EFSP and EFM vendor to clearly define what they are
>supporting.  
>
>3.	It eliminates uncertainty for the courts. 
>
>4.	It allows jurisdictions to group together and influence each other. 
>
>5.	It is a natural process for vendors who desire to target a specific
>market. 
>
>6.	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
> 
>
>
>