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.
Donald L. Bergeron
Systems Designer
LexisNexis
donald.bergeron@lexisnexis.com
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 Salt Lake City.
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, Box 23
Regina, New Mexico
87046
505-289-2164
505-289-2163 (fax)
505-780-1450 (cell)