With regard to Dallas' most recent questions,
they raise a general issue about practical implementation of
the standards. Understandably, he is uneasy with Court Policy because it is
subject to considerable variation, which will undoubtedly makes the task of
programming more complex and difficult and as a result,
expensive. Just as there is the CMS-API, a CP-API may
become necessary in order to encapsulate the logic in a component that
gives standardized outputs for standardized inputs. In other words, it may be
necessary to create court policy as a web service with standard parameters being
accepted and returned to EFSP's.
I think that Dallas has the greatest experience
within the TC of what it takes to implement a LegalXML standard, albeit an early
one and his concerns should be dealt with seriously.
I personally don't have an answer for Dallas because I find it difficult to
assess programming issues in a vacuum, without a concrete task to be solved that
exposes the weaknesses of a type of a priori thinking that I associate with
standards creation, but I am in favor of standardized inputs and outputs for
court policy as a way of creating an API. In the meantime, I think we need to
encourage implementation, even if only in a few courts are involved to
begin with and with the weaknesses we acknowledge need fixing, so that we can
learn from the experience of all of the participants, and improve the process
for the next go-around.
However, there is another dimension to the comments of Dallas and others.
We are beginning to look at a real possibility of three standards for XML
usage in court filings: one from this TC, another from the California AOC, and a
third from the US Administrative Offices of the Courts. Just as developers like
Dallas should cringe at this proliferation, so lawyers may balk at sorting
through EFSP's to determine which one services a court or courts that the
lawyer needs to access. It is true that large firms with mangerial or IT staff
may be able to take on such a task, but in a state like Arizona, over 50% of the
bar is sole practitioners, who will need to be spoon fed and offered
bargain-basement or zero pricing if electronic filing will ever
succeed. This may require a uniform national infrastructure for electronic
filing, and we should be prepared for the possibility that it will happen
under federal aegis if we are unable to make it happen in the TC, with or
without California.
I agree with Tom that the TC must move forward with what we have
now, notwithstanding any doubts and concerns for the immediate future, but
I think we should begin thinking of a single uniform XML standard, and how to
best reach that goal.
----- Original Message -----
Sent: Monday, October 21, 2002 5:20
PM
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
----- 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>