MHonArc v2.5.2 -->
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
The current Utah LegalXML implementation uses the CourtFiling 1.1 DTD.
Dallas Powell
Tybera Development Group
www.tybera.com
----- Original Message -----
From: "Lewis, Diane" <Diane.Lewis@usdoj.gov>
To: "'John Messing'" <jmessing@law-on-line.com>; "'Dallas Powell'"
<dpowell@tybera.com>; <Tom.Clarke@courts.wa.gov>;
<Shane.Durham@lexisnexis.com>; <legalxml-courtfiling@lists.oasis-open.org>;
<legalxml-courtfiling-policy@lists.oasis-open.org>
Sent: Tuesday, October 22, 2002 11:33 AM
Subject: RE: [legalxml-courtfiling] RE: [legalxml-courtfiling-policy]
Sdurham - RE: Final Call - Cour t Filing Policy Requirements
> Last night i read over the recent TC discussions... i appreciate the
comments made by all especially since i am not familiar with the Georgia
test implementation or the origins of the architecture that was conceived
some time ago... so my inquiries and
> comments are based on a "sky" view and the desire to move ahead on the
2.0 specification definitions which would include requirements coming from
1.1 specification test findings...
>
> 1. Resolution of Query/Response:
> DL concurs with Shane and Dallas...
> 1.1 is frozen. any testing of the 1.1 specification sounds like it will
need to "extend" the specification to meet the individual court functional
requirements as defined in national or local rules. We will learn about
these extensions from the 1.1 sp
> ecification test report(s).
>
> I spoke to Karl Best this morning about the version control aspect to our
discussion. The TC can use whatever conventions have meaning to all TC
members as we move forward. the proposed 1.1.a; 1.1.b; 1.1.c; convention
should be considered by those
> TC members implementing the specification 1.1 in pilot or production
development phases. Those testing the specification have no need to track
such amendments to the "1.1" static specification.
>
> 1a) Were the lessons learned from Georgia incorporated into the 1.1
specification?
>
> the place holders described in TC messages must have been placed there for
a reason(s)? or is the specification approved as 1.1 incomplete?? and not
extensible by TC developers who are implementing in pilot or production
environments? Is it complete e
> nough to test specification?
>
> DL Proposed conclusion: move forward with testing the specification
1.1.... as suggested by Dallas and Shane... TC members who are implementing
1.1 as developers will share their findings and identify changes /new stuff
to incorporate into specificatio
> n (fill-in placeholders) as discoveries are made.
>
> DL Proposed Action: Nov 5 TC teleconference bring thread to closure ...
>
> 2. How many TC Members or non-members are currently
developing/implementing "versions" of LegalXML specification 1.0; 1.1?
> I was told yesterday in a meeting with Administrative Office of U.S. Court
technical representatives that there are no State court or Federal court
implementations of LegalXML specifications. Yet John Messing... notes below
that there are?
>
> from my attendance at two OASIS LegalXML face to face meetings ... i
understood that Utah State Court is building on spec version 1.0?
Washington, King County, is developing system for 2003 implementation on
1.1 spec? AOC has just started a vendor
> driven development of electronic court filing system specific to the
requirements of California state courts based on Georgia LegalXML findings?
> OCXI, as i understand it, is a proposed collaborative effort to develop
middleware that would apply the existing LegalXML specification (1.1)or
perferably version 2.0 if ready in time?
>
> DL Proposed conclusion: Those TC members who want to "test" the Court
Filing specification 1.1 I would ask to identify themselves during the Nov 5
TC teleconference. Those members who volunteer to test the specification 1.1
will need to map out the appr
> oach to be taken in specification testing based on TC guidance provided.
>
> I concur with Tom Clarke message 10/17 2:59pm group levels 1 and 2 as
basic conformance requirement level and group conformance levels 3&4 for
next level of conformance. When developing test criteria suggest this
approach.
>
> 3. Status Court Policy Framework:
> explanations to my inquiries about this specification in Boston... made me
start thinking about this "document" as a "collaboration profile"... as
expressed in the ebXML documentation i had recently read.
> Given the discussion to date and my own confusion as to how best to define
and address the repository, "collaborative" profile or any semantic content
issues that may surface during test of the specifications i think we should
put aside this document fo
> r now.
>
> DL Proposed Action: Place the Court Policy Interface/Framework document on
the shelf until after 1.1 specification testing is completed and TC analysis
of test specification findings have been completed.
>
> Suggest Court Policy Interface subcommittee focus immediate efforts on
researching existing XML based standards that can be leveraged in some way
to support existing OASIS LegalXML technical specifications Court Filing,
Court Document, Query/Response...
> .
>
> 4. DL current OASIS Legal XML activity: I am in the process looking over
the Court Document 1.1 specification, in Boston i volunteered to support
that subcommittee.... i am reviewing the contents of a zip file recently
provided... with an eye to version
> 2.0.
>
> DL travels to CALIF.. to attend first face to face OASIS LegalXML IJ TC
next week. hope to see some of you there... otherwise will hear your voices
during the teleconference scheduled for Nov 5th... cheers diane
>
>
>
>
>
>
>
> -----Original Message-----
> From: John Messing [mailto:jmessing@law-on-line.com]
> Sent: Tuesday, October 22, 2002 12:40 AM
> To: Dallas Powell; Tom.Clarke@courts.wa.gov;
> Shane.Durham@lexisnexis.com;
> /DDV=legalxml-courtfiling@lists.oasis-open.org/DDT=RFC-822/O=INETGW/P=GO
> V+DOJ/A=TELEMAIL/C=US/;
> /DDV=legalxml-courtfiling-policy@lists.oasis-open.org/DDT=RFC-822/O=INET
> GW/P=GOV+DOJ/A=TELEMAIL/C=US/
> Subject: Re: [legalxml-courtfiling] RE: [legalxml-courtfiling-policy]
> Sdurham - RE: Final Call - Cour t Filing Policy Requirements
>
>
> I share the misgivings that others have expressed about the lack of
uniformity between CourtFiling 1.1 and QnR, and the other standards in the
1.1 family, and on that issue I think that Tom Clarke has probably stated
views that are closest to my own and
> in a most succinct manner.
>
> 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 ta
> sk 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 acknowled
> ge ne
> ed 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 Admini
> strative 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 fi
> rms w
> ith 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 -----
> From: Dallas Powell
> To: Tom.Clarke@courts.wa.gov ; Shane.Durham@lexisnexis.com ;
legalxml-courtfiling@lists.oasis-open.org ;
legalxml-courtfiling-policy@lists.oasis-open.org
> 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 requi
> re 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 I
> nterface. 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 proce
> ss 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 allo
> ws 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 sta
> ndardized 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 th
> e 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
> creat
> e 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
>
>
>
>
>
>
> ----- Original Message -----
> From: <Tom.Clarke@courts.wa.gov>
> To: <Shane.Durham@lexisnexis.com>;
<legalxml-courtfiling@lists.oasis-open.org>;
<legalxml-courtfiling-policy@lists.oasis-open.org>
> 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