[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [legalxml-courtfiling] Query And Response Work-In-Progress
|
There are a couple of items that your request
exposes to me as issues we would like to present.
First:
Splitting a DTD and referencing a separate
DTD through external parameter entities could be less reliable. Also
according to XML HandBook - Third Edition 50.5.1 "XML processors are allowed, but not required, to
validate an XML document when they parse it. The XML specification allows
a processor that is not validating a document to completely ignore declarations
of external parsed entities ( both parameter and general)."
My only concern is that it may cause difficulties for some products. I
know that in the Georgia Interoperability test, validating documents vs. parsing
for syntax was an issue for some vendors. Some document instances
were including references to a DTD that were local to some
other system that we did not have access to, so when we loaded the
document instance for parsing we had to write a kludge which dealt with DTDs
that we could not find.
Second thought:
"To avoid
explicitly re-defining all of the CourtFiling elements into the QueryResponse
DTD" suggests that it has already been agreed to separate
Filing & Confirmation from Query & Response into two DTDs
because they do not belong together. I don't know if the TC has
already agreed to this or not? However, our experience says that we need
more than confirmation associated with a filing. First let me refer
to Catherine Krause's status report attached to this message. She points
out that the confirmation elements do not provide adequate definitions to
include all the information they wanted to include when responding to a
filing. Bullet item 4 & 5 under lessons learned indicate
they needed a place where they could include error messages and "We had wanted to include the documentTitle in the filing
receipt because the received message would be less than helpful
when it references a Filename or Path name only."
Our experience was even more difficult because Utah
allows case initiation and automatic collection of fees through
credit cards. We needed significantly more data included in our response
to a filing. Our response is asynchronous and provides for several
confirmation responses to a single filing. In addition to our confirmation
responses, we found it necessary to include a document that included
documentTitle, authorization codes for master card, amounts charged, Judge
assigned to the case, error messages and so forth.
We realize that the definition of a Response for
LegalXML only describes it in relationship to a Query, but for us, we would
propose the idea that a LegalXML Response document may be returned due to a
filing and not just a Query or else the confirmation allow the inclusion of
documents.
Dallas
----- Original Message -----
|
--- Begin Message ---
- From: "John M. Greacen" <john@greacen.net>
- To: Court Filing List <legalxml-courtfiling@lists.oasis-open.org>
- Date: Sat, 28 Sep 2002 07:15:36 -0600
Here is a short but very helpful status report on the use of the 1.1 specification in King County. Catherine and Roger have asked for comments and suggestions on one issue they have encountered. Does anyone have any ideas for them? -- John M. Greacen Greacen Associates, LLC. 18 Fairly Road Santa Fe, NM 87507 505-471-0203--- Begin Message ------ End Message ---Title: ECF 1.1 spec testing status report from King County, Washington
- From: "Krause, Catherine" <Catherine.Krause@METROKC.GOV>
- To: "John Greacen (john@greacen.net)" <john@greacen.net>
- Date: Fri, 27 Sep 2002 13:06:10 -0700
John:
Per my prior message, King County's electronic filing pilot project has had some significant delays due to issues unrelated to Court Filing 1.1. We are currently working with our vendor to ensure that our business requirements will be met, and are working on a detailed schedule of remaining tasks. We do know that our pilot will be delayed until 2003.
We had started our acceptance testing for the e-filing pilot system when significant issues were found that resulted in the delays I mentioned. This is what we have found to this point in the project regarding Court Filing 1.1:
- Our pilot project is intentionally limited in scope:
- It primarily includes filings where a King County web site is acting as the EFP (a.k.a. EFSP), creating a Court Filing 1.1 filing envelope that is transmitted to our King County EFM, which returns a Court Filing 1.1 confirmation envelope with the results of the filing. The results of the filing are displayed to the user via the web site as either error messages for "rejected" filings or a filing receipt for "received" filings. These are the only two dispositions that we are using.
- Even though the EFP and EFM are both King County entities, we have architected our system so that these are separated. The King County EFM can also receive Court Filing 1.1 filing envelopes created by other EFPs, such as commercial EFPs, law firms, etc., and return the appropriate response via a Court Filing 1.1 confirmation envelope to those EFPs. During our acceptance testing, the intent is to verify that the system will accept filings transmitted directly and not created by our web site. But, no actual outside EFPs are participating in our pilot.
- We are not including an e-commerce component in our pilot. Accordingly, we could not allow filings in a case that would require fee payments, even though we could accept other filings that would not.
- We are not including case initiation in our pilot because they often require a fee, provision of a case schedule, and other complexities that we wanted to implement separately after we had evaluated the technology and business processes utilized during the pilot.
- We are using user IDs and passwords for filer authentication by our EFP. We are not requiring digital signatures for filings originating outside the court. Filings originated by the court are not included in our pilot.
- Our clerk's office does not process attachments separately from the lead document. Thus, we are including all of the document content in the lead document and are not testing any of the attachment data elements.
- Lessons learned thus far during the project:
- We included the need to use Legal XML Court Filing standards in our RFP, and also in the Requirements for our pilot system developed by our vendor. We also included information regarding the system architecture, and the need to separate the EFP and EFM functions per our draft state technical standards for E-Filing. Despite this, our vendor did not follow these guidelines in the initial versions of the pilot system Design; they had responded to that direction by trying instead to give us something they thought was equivalent or better than the "limited" DTD approach of 1.1. The lesson for others would be that vendors may tend to look for updates, substitutions, and shortcuts that would in effect lead a system to abandon its direct tie to the standards. It should be noted that our vendor has not been a participant in Legal XML up to this point.
- When we did successfully start working with the vendor on the details of Design for the system to include the Court Filing 1.1 envelope, we found that some aspects of 1.1 are not clear enough to show us unambiguously which elements relate to our data items. After several meetings, we did come to what at the time seemed to be a Design that incorporated all of the data elements needed for our pilot, based on our interpretation of the Court Filing 1.1 DTD.
- During acceptance testing, we were able to successfully transmit documents from our EFP (filing web site) to our EFM via a Court Filing 1.1 filing envelope.
- During acceptance testing, we were able to successfully transmit confirmation of a filing from our EFM to our EFP via a Court Filing 1.1 confirmation envelope; we used the memo field to transmit error messages for "rejected" filings and displayed a filing receipt for "received" filings.
- We had an issue with the filing receipt that is a discussion item for resolution by our vendor. We had wanted to include the documentTitle in the filing receipt because the received message would be less than helpful when it references a Filename or Path name only. If the receipt might be brought to the Court in the case of a question about the filing, the Court would want to see the Title, not some reference number or path name. Note that documentTitle is not included in the Court Filing 1.1 confirmation envelope. Per our vendor, that was why they didn't include it. I believe it could be included, either in the courtDocumentReference data element (since that is court defined) or by our EFP (web site) based on the leadDocument id referenced in the confirmation. But, this issue hasn't been resolved, and input from the committee on how this could or should have been handled would be welcome. This issue has led me to review other data elements utilized by the vendor for transmission, and I feel some others have been misinterpreted. In particular, some data extensions were included for internal purposes, and I am not yet convinced they are necessary. If we determine that we did need to utilize data extensions, we will provide that information to the TC for consideration for additions to Court Filing 2.0.
- We will develop a list of the data elements we have used, indicating the interpretations we made regarding how Court Filing 1.1 would be used. We will not publish such a list until after we have gone through our requirements review and redesign processes.
- We did not have an opportunity to test the outside EFP to King County EFM functionality before our project was put on hold. This test will occur when our acceptance testing resumes.
We hope that our report can provide two things for the TC: 1) Clarifying how to use 1.1 (to show, for example, how to treat a document title) and 2) Providing experience from which some of the requirements for 2.0 can be drawn.
As I mentioned, I am unable to attend the Boston face-to-face meeting. Roger Winters will be attending the phone portion of the meeting. If you would like to share this brief report with the TC in Boston as part of proposed agenda item 8, you are welcome to do so. We still are likely to make some changes in the specific data elements in the envelope that we use, and our tests thus far have been generally successful but it would be premature to state that we have yet drawn any final conclusions. We had hoped to have more detailed results for the TC, but unfortunately a formal result of our experience implementing Court Filing 1.1 won't be available until some time in 2003.
I would be happy to respond to any questions from TC members as a result of the discussion in Boston via the list after I return from vacation.
Sincerely,
Catherine Krause
E-Filing Project Manager
King County Department of Judicial Administration
(206)296-7860
catherine.krause@metrokc.gov
AndRoger Winters
Electronic Court Records Manager
King County
Department of Judicial Administration
516 Third Avenue, E-609 MS: KCC-JA-0609
Seattle, Washington 98104
V: (206) 296-7838 F: (206) 296-0906
roger.winters@metrokc.gov
--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC