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 <dpowell@tybera.com>
- To: Tom.Clarke@courts.wa.gov, Shane.Durham@lexisnexis.com,legalxml-courtfiling@lists.oasis-open.org,legalxml-courtfiling-policy@lists.oasis-open.org
- 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
----- Original Message -----
Sent: Monday, October 21, 2002 1:52 PM
Subject: [legalxml-courtfiling] RE:
[legalxml-courtfiling-policy] Sdurham - RE: Final Call - Cour t Filing Policy
Requirements
> I agree that we need to have a consistent architectural approach to
Legal
> XML messaging and that it is lacking now. I'm not sure that
is a show
> stopper for Court Policy. All of its implied API's must
be implemented
> consistently in EFM and EFSP components in real life, but
the current spec
> says almost nothing about how that implementation would
occur at the
> component level.
>
> -----Original
Message-----
> From: Durham, Shane (LNG-CL)
[mailto:Shane.Durham@lexisnexis.com]
> Sent: Monday, October 21, 2002
10:24 AM
> To: 'legalxml-courtfiling@lists.oasis-open.org';
> 'legalxml-courtfiling-policy@lists.oasis-open.org'
> Subject: [legalxml-courtfiling-policy] Sdurham - RE:
Final Call - Court
> Filing Policy Requirements
>
> >>
Please give a final thoughtful read. I thank you in advance for your
>
input and involvement. <<
>
>
> I have attached a word
document with my comments.
> (use ms-word's 'view comments')
>
> A prior reviewer's comment's "RLW" are also within the document.
Those are
> not mine.
>
>
> General comments and
conclusion:
>
> As I stated in Boston, I think LegalXML 1.x is not
consistently structured
> to facilitate an associated Policy
structure. This requirements spec, while
> a respectable and very
decent starting point, contains a deep assumption
> that policies will be
specifically developed against CourtFiling 1.x, QnR
> 1.x, Document 1.x,
etc. I would suggest we shouldn't be talking about
> CourtFiling
policies.. or QnR policies.. but, simply, "LegalXML Message"
>
policies. Unfortunately, in LegalXML 1.x, there isn't really a
consistent
> concept of a 'LegalXML Message'. CourtFiling is a bit
different than QnR...
> and is a bit different than Document. As it
stands, they would need
> independent policy structures for each of those
API. And, 'policy' can be
> ferociously complex... let alone having
to develop it against three models.
>
>
> The document
sufficiently describes the requirements for a LegalXML 1.x
> policy
set. However, it reveals to me, that a reasonably implement-able
>
policy set for LegalXML 1.x is not do-able. I think the work is too
complex
> because the underlying Filing, Document, and QnR specs do not
follow a very
> consistent model (which is simply a sign of an immature
API... it naturally
> happens... no offense to the development's
participants, including myself).
>
>
> So... I suppose I
conclude:
>
> ** I can not approve the spec with respect to its
intended use for LegalXML
> 1.x, on the grounds that such work is not
technically feasible and that such
> work would not be implement-able.
Furthermore, I do think that LegalXML 1.x
> can facilitate the development
of any feasible Policy system as currently
> envisioned by the LegalXML
participants. **
>
> (I do not intend for my position to become a
filibuster. If I am virtually
> alone in this opinion, I will
withdraw my dissenting 'vote' and allow the
> consensus to
proceed.)
>
>
> With respect to LegalXML 2.x, and the hopes
that it has a more
> 'policy-friendly' approach to its API, a policy
requirements spec, at this
> time, would be a bit premature but it
certainly should be considered a
> serious working draft as LegalXML 2.x
takes shape.
>
> - Shane Durham
> LexisNexis
CourtLink
>
>
>
>
----------------------------------------------------------------
> To
subscribe or unsubscribe from this elist use the subscription
> manager:
<http://lists.oasis-open.org/ob/adm.pl>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC