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
We anticipate setting up a complete system for testing interoperability. We
are in discussions with a vendor to provide licenses for the components we
need to reproduce the integration we have done between Utah's CORIS Case
Management System (need database license) and the Document Management System
( need license) that Utah utilizes to scan documents and store
electronically filed documents.
I will create a document that exposes our dates for live filings, the types
of filings, the different type of interoperability tests that we anticipate,
and how others can participate. I anticipate having this document before
Nov. 5th. Currently writing a document on how to ease the pain for users
creating XML right now for a vendor.
It is our position that we will document and publish the details of what an
EFSP must do to communicate to the EFM that is installed. I will also
provide why we are doing what we are doing in the "place holder" areas as
feedback for lessons learned ( that should be learning not learned).
Dallas Powell
Tybera Development Group
www.tybera.com
> DL - Do you plan to nominate your project for "testing specification 1.1"
process... in the coming months? dl
>
>
> Dallas - The current Utah LegalXML implementation uses the CourtFiling 1.1
DTD.
>
> >DL- 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>
>
>
> ----------------------------------------------------------------
> 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