[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
thank you dl -----Original Message----- From: Dallas Powell [mailto:dpowell@tybera.com] Sent: Tuesday, October 22, 2002 4:56 PM To: Lewis, Diane; 'John Messing'; 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 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> ---------------------------------------------------------------- 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