FW: ECF 3.0 implementaion in illinois

["John M. Greacen" <john@greacen.net>]

Jim and Christoph -- Can you respond to Mr. Jahn?  Thanks.

> -----Original Message-----
> From: Jeremiah Jahn [mailto:jeremiah@goodinassociates.com]
> Sent: Friday, May 12, 2006 9:07 AM
> To: john@greacen.net
> Subject: ECF 3.0 implementaion in illinois
> 
> Hi, My name is Jeremiah Jahn, and I work for a company called Goodin
> Associates. We are the CMS Vendor for approximately 82 of the 102
> counties in Illinois. We are currently trying to implement ECF 3.0 for
> an e-filing pilot project we are working on, as well as evaluating it
> for use as the integration pathway between our State's Attorney
> application and our CMS. I'm having a number of issues involving a
> little too much flexibility in the standard. Most of these seem to be
> addressable by the <CourtExtension><ExtensionReference> section of the
> schema, however there seems to be very little information as to what
> these schemas can be implemented. I was wondering if you new of any
> thorough examples.
> 
> 
> just for your reference I've included a list of my current issues, but
> like I said should addressable with the court extension mechanism. Thank
> you for any direction you can offer.
> 
> ECF 3.0 issues
> 
> 
>       * Too many choices
> 
>               * first name, last name, fullname
> 
>       * lack of constraints
> 
>               * inability to dictate which choice a court will accept
> 
>       * lack of information on null-ability of parameters in required
>         operations
> 
>               * the spec doesn't indicate what happens if one of an
>                 operations parameters are null.
> 
>       * lack of abstraction
> 
>               * could have made the standard abstract in places to allow
>                 a court to effectively trim the schema to what it would
>                 accept and require
> 
>       * lack of data format constraints
> 
>               * inability of court to dictate format of values in schema
>                 esp person name
> 
>       * multiple files making IDREFS impossible between different data
>         elements
> 
>               * persons listed in CoreFilingMessage and persons listed
>                 in CaseTypeMessage
> 
>       * Inability to specify document types in CourtPolicyMessage
> 
>               * Can be done through extension, but this is not made
>                 clear in the spec.
> 
>       * Operations far too inefficient.
> 
>               * Filing fees can be transmitted in the court policy,
>                 since they don't change very often.
> 
>       * Spec falls short in indicating the intended uses of elements, or
>         why certain decisions were made.
> 
>       * Inability to specify valid id type codes in court policy
> 
>               * IDTypeText cannot be constrained for example
> 
> 
> 
> 
> 
> In West Union, Ohio, No married man can go flying without his spouse
> along at any time, unless he has been married for more than 12 months.