legalxml-courtfiling — archive

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

From: Christopher Durham
To: [email protected]
Date: Fri, 07 Oct 2005 15:25:00 -0000

MHonArc v2.5.0b2 -->

legalxml-courtfiling message

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

From: [email protected]
To: [email protected]
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:[email protected]]
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 11^th 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)