legalxml-courtfiling — archive

RE: [legalxml-courtfiling] Agenda for Tuesday conference call and subcommittee report

From: Donald Bergeron
To: [email protected]
Date: Sun, 17 Apr 2005 20:34:00 -0000

MHonArc v2.5.0b2 -->

legalxml-courtfiling message

Subject: RE: [legalxml-courtfiling] Agenda for Tuesday conference call and subcommittee report

From: "Bergeron, Donald L. (LNG-DAY)" <[email protected]>
To: "'John Greacen'" <[email protected]>, "'Electronic Court Filing Technical Committeee'" <[email protected]>
Date: Sun, 17 Apr 2005 16:33:57 -0400

Please see my comments below:

As I noted in the meeting, I will not be able to attend the conference call due to a high priority conflict.

I believe the items below are sufficient to bring this to closure. Therefore, I support the closure of this document.

Regards,

Don

Donald L. Bergeron
Systems Designer
LexisNexis
[email protected]
O 937-865-1276
H 937-748-2775
M

Agenda

New introductory materials for the requirements document
200 -- Bergeron -Consider changing "cannot" to "cannot and shall not."[Bergeron] That is not the intent of my change. I do not see that my recommended language change changes the behavior. It only strengthens that the metadata must come from the envelope construct not from the payload. Whenever, you see the word consider in the comment of mine it is always optional. I'm suggesting a strengthening of the language. Under the rules consensus, I can live with this.

Subcommittee comment - Don's suggested change would prohibit the attachment of an XML instance as a document in the payload. We do not believe that is the TC's desire. We merely want to make clear that Court Filing Blue will not support accessing tagged material contained in an XML instance in the payload.

1219 - 4 .4 .4 through 4.4.6 -- Bergeron - Define the behavior when a document within a case is sealed and may be hidden from the docket itself, visible to the docket but unnamed and unretrievable, visible in the docket named the and unretrievable. [Bergeron] What I understand from your comments, is that this will be completely controlled by the court in the management of the court record. Based on that, I have no heartburn and accept the recommendation of the subcommittee.

Subcommittee comment - Most courts merely remove sealed or inaccessible information from a response without providing any notification or explanation to the requester. Providing notice of the exclusion of information may disclose its existence, in contravention of the sealing or exclusion policy. The subcommittee recommends only that the court set forth in its court policies a disclosure of its general practice to exclude sealed and inaccessible information from the information returned in response to a query.

1316: McElrath - Why not make this an extension of get case? Is this where a filer can query for a standardized form for the court? If so, then this is useful. If not, then it seems more appropriate as an extension to "Get Case" as a query for a document related to a specific case.

Subcommittee comment - The "Get Document" query was approved in . We believe it is necessary. [Bergeron] This is a function of editorial choice and supported by precedent from the last face-to-face. I urge you to accept it.

1392-1398: McElrath - Should be two scenarios. 1) Calculate fees based on document type or declared characteristics and 2) Calculate fees based on document specifics from processing of document. For scenario 1, courts would use very little bandwidth and processing power, and this query would give back fees quite quickly and simply with small efficient messaging. For scenario 2), courts can run through any type of processing that they want for the full document to determine fees, but since courts have the choice of 2 scenarios, the documents do not always have to be transmitted twice which would help out courts with low bandwidth connections and conserve processing efficiency for high volume courts and high volume filers.

Subcommittee comment - We believe that this is resolved by allowing the filer to opt out of the calculate fees query, but we believe the TC should decide.[Bergeron] This appears to be a reason will commendation.

1769-1788: Cabral - The directory should include the necessary metadata and interfaces to allow MDEs to search for one another.
1769-1788: McElrath - This needs to be deleted. This is nice if we are specifying software, but we should not be in that realm at all. Our job should be to specify standards for data transmission and communication, not to architect out specific software modules. We are deep inside the black boxes again and need to pull out of that area. For the specification to be successful and to not validate any specific way of doing things inside a particular software, the black boxes should be left alone.

Subcommittee comment - It is clear that MDEs need to know each other's addresses. But whether that requires a formal process and, if so, what that process should be, needs to be resolved by the TC.[Bergeron] I agree this does not need to be in the requirements document. However if it is in I can live with it.

John M. Greacen

Greacen Associates, LLC

HCR 78,

505-289-2164

505-289-2163 (fax)

505-780-1450 (cell)