Agenda for Tuesday conference call and subcommittee report

MHonArc v2.5.0b2 -->

















legalxml-courtfiling message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Agenda for Tuesday conference call and subcommittee report




From: "John Greacen" <>
To: "'Electronic Court Filing Technical Committeee'" <>
Date: Sat, 16 Apr 2005 13:39:17 -0600














Here are the details for Tuesday’s conference call.  I hope
that all voting members are able to participate.

 

Leader's Name: John Greacen

        Day/Date: Tuesday, April 19, 2005

        Time of call: 1:00 to 2:00 pm Eastern time

        Conference Dial-in:
512-225-3050

        Conference Guest Code:
84759#

        Number of lines needed:
Anticipated Total = 40

        Duration of the call: 1 Hour

        Leader's Phone Number: 505-780-1450

 

I attach the report of the subcommittee of Tom Clarke, Shane
Durham, Eric Tingom and me that reviewed the comments
submitted on the requirements document.  The report includes new
introductory material for the requirements document.  It identifies
specific items for further discussion by the TC during this conference
call.  And it gives a specific response to each comment submitted.

 

The agenda for the conference call will include the
following items and any additional items raised by persons who submitted
comments who are not satisfied with the subcommittee’s response.

 

Agenda

 


 New introductory materials for the requirements
     document
 200 -- Bergeron –Consider changing
     “cannot” to “cannot and shall not.”


 

      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.
     


 

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 Salt Lake
  City.  We believe it is necessary. 

 


 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.

 


 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.

 

 

John M. Greacen

Greacen Associates, LLC

HCR 78, Box 23

Regina, New Mexico 87046

505-289-2164

505-289-2163 (fax)

505-780-1450 (cell)

 






Report of comments subcommittee4-16-05.doc












[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]