>> 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.
The review committee, consisting of
Jim Cabral, Scott Came, Tom Clarke 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
78 Box
23
Regina,
New Mexico 87046
505-289-2164
505-289-2163
(fax)
505-780-1450
(cell)
john@greacen.net