RE: [legalxml-courtfiling] Review of comments on domain models, GJXDM mapping, and schemas - GetFilingStatus and GetDocument

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] Review of comments on domain models, GJXDM mapping, and schemas - GetFilingStatus and GetDocument




From: 
To: 
Date: Fri, 7 Oct 2005 08:30:43 -0700 










 

 
>> 
Whether the status of a 
filing should be included within the GetFiling Query or continue to reside in a 
separate GetFilingStatus Query
>>Whether 
we need a query that returns a single document contained in a filing, 
particularly for service.
 
FilingReview.GetFilingStatus() 

  
  A 
  Compromise: 
   
  I will discontinue 
  my discussion of the GetFiligStatus() query if...
   
  ...we can change  'GetFiling()'  
  response to include the filing's status .
   
  We should not demand a 
  requestor make 2 distinct query 
  calls in order 
  to obtain the details and status of a filing.   
  
   
  If, in the name of system optimization, we 
  think it is critical that we be able to get filing status without 
  obtaining the filing 
  details...
  ....then, surely we can agree that it is equally 
  important that someone be able to get status and details in a 
  single 
  call. 
   
  Why?
   
  Everyday experience shows us that it is usually the 
  number of trips, not the amount of data per trip, that most often slows down a 
  system.
   
  It is this same 'fewer trips' philosophy that has 
  guided the group to develop a relatively complex GetCase() query which can 
  return or exclude CaseParticipants, RegisterOfActions, and 
  CalendarEvents.  We have agreed that someone should be able to get a 
  lot of case data, such as participants and calendar, from a 
  single call.  
  That same philosophy should be 
  applicable to 
  GetFiling().
   

FilingReview.GetDocument()

  >> All attachments are 
  included in the GetFiling Query because it returns the entire filing 
  message
  >> 
  Therefore 
  we see no reason for a separate query to obtain an individual document from a 
  filing (as contrasted with a query to obtain a single document from the 
  court’s official records).
   
  Hmmm....
   
  We are currently working on the GetCase() 
  query.
   
  That query's response will be able to include a 
  register of actions, which then include  court 
  documents.
   
  For the response to GetCase(), we have agreed that 
  the register of actions could be too large to include document 
  content.
   
  NOTE: That statement is only 
  meaningful when document content is being directly expressed as MIME, or 
  as a message attachment (DIME, MTOM..) 
  
  When document content is expressed as an 
  HREF/external link, then, this 'too large' 
  scenario is moot.
   
  And so, with that scenario in mind, we have 
  defined a GetDocument() query, so that a requestor could get the court's 
  document content which was not expressible in the GetCase 
  response.
   
  That scenario and logic is sound to 
  me.
   
  And, I think that same set of 
  principals applies to our GetFiling() process. 
  
   
  A 
  large filing *could* have so many documents ( or even one very large document) 
  that it is impractical for the FilingReview process to return the document 
  content anytime someone wants to review the filing 
  details.
   
  Whatever problem you imagine with respect to 
  retrieving the CourtRecord's documents, that same problem will exist 
  when working with FilingReview's documents.  Likewise, whatever 
  solution you apply to the CourtRecord, should also be applicable to 
  FilingReview.  
   
   
  So, here's my current 
  proposal:
   
  If the query recipient is using HREFs ( 
  stand-alone links ) to express their document 
  content:
  
    In both GetCase() and GetFiling(), the query 
    recipient should just include those HREFS when assembling their 
    GetFiling or GetCase 
response. 
    The query caller can choose to traverse those 
    HREFs to get the content if/when they want 
    it.
  If the query recipient is using MIME encoding, 
  or URIs which refer to message attachments (DIME/MTOM/etc) to express their 
  document content:
  
    In both GetCase() and GetFiling(),  the query 
    recipient should NOT include those URIs when assembling the GetFiling or 
    GetCase response.  The lack of a URI will be the signal to the 
    query caller that they must make a special GetDocument() call to obtain 
    the document 
    content.
   
  For the CourtRecordMDE, we continue to have this 
  query:  
      GetDocument(courtId, 
  CaseTrackingId, documentID)
   
  And, for the FilingReviewMDE, we add this query: 
  
      GetDocument(filingId, 
  documentID). 
   
  
  Again, neither of these queries would need to be 
  implemented should the court chooses to use HREFs to express document 
  content.
   
- Shane 
Durham
LexisNexis
 
 

 
 



From: John M. Greacen [mailto:]
Sent: 
Wednesday, October 05, 2005 9:34 AM
To: Electronic Court Filing 
Technical Committeee
Subject: [legalxml-courtfiling] Review of 
comments on domain models, GJXDM mapping, and schemas




The review committee, consisting of 
, ,  and me, have reviewed the 
comments submitted by Don Bergeron, Shane Durham and Dallas Powell.  The committee report is attached.  

The committee disagreed with twelve 
of Shane’s comments.  Those twelve 
issues are listed at the beginning of the report and will be placed on the 
agenda for the ECFTC conference call scheduled for next Tuesday, October 
11th at 1:00 pm Eastern.  


Please review the committee report 
and Shane’s comments (the committee report merely summarizes his comments; you 
need to read his comments to fully understand and appreciate them) prior to the 
meeting so that we can reach closure on these issues next 
Tuesday.

Next Tuesday’s agenda will include 
additional items if they are ready for review by that time.  It will be an important TC 
meeting.

John 
M. Greacen
Greacen 
Associates, LLC
HCR 


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]