RE: [legalxml-courtfiling] 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: RE: [legalxml-courtfiling] Agenda for Tuesday conference call and subcommittee report




From: "Bergeron, Donald L. (LNG-DAY)" <>
To: "'John Greacen'" <>,       "'Electronic Court Filing Technical Committeee'" <>
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



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)

 


















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

--

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