[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
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 specification 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 enough 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 specification (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 approach 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 for 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 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 -----
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 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.
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