[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-courtfiling] Maricopa County issues
I'd
like to respond to a couple of the questions you've raised, Jim: 3. Can we add an
indicator to the machine-readable court policy to indicate whether filings with
multiple lead documents are supported? I'd appreciate an
example of how "multiple lead documents" works. I'm in a
court where we don't have multiple lead documents (so far as I know), but
we do have instances where multiple documents are expected to be filed at the
same time. Technically, they are independent documents and each could have its
own attachments. Attachments are linked to their respective "lead
documents" (electronically "stapled"). The documents are
linked because a rule or process says they are to be filed at the same time -
but they are not linked as electronic objects (no electronic "staple").
4. How could ECF 3.0
be used or extended to support Judge Review and approval of documents, draft
orders, etc.? Does
this refer to a process of submitting documents to a judge before
e-filing is done? If that is the case, isn't it the judge who's
e-filing (after having approved, reviewed, or whatever). If that's the
scenario, I would think that 3.0 would not pertain since e-filing wouldn't
begin until after the judge's review. There is
some desire here in One
could argue that draft orders and courtesy copies (any documents not directed
to the clerk for processing into the case file) are out of scope for 3.0. Is
Maricopa's question addressing different business processes than these? Roger Winters Editor, OASIS LegalXML Electronic Court Filing
Technical Committee and Program and Project Manager King County Department of Judicial
Administration 516 V: (206) 296-7838 F:
(206) 296-0906 roger.winters@metrokc.gov From: Cabral, James E.
[mailto:JCabral@mtgmc.com] ECF TC:
Here are several
issues/questions Technical Questions
1. Currently, we
provide metadata for splitting an attached document into parts/chunks in order
to keep each part under a maximum attachment size. However, in the web
service messaging profile, each of these attachments are still part of the same
SOAP message and thus must be recombined at the receiving web server into a single
HTTP POST. According to Maricopa, most web servers (e.g. ASP.NET, Apache,
etc.) default at a maximum POST size of 10MB. Although the maximum POST
size can usually be changed in the web server configuration, this could be an
obstacle to implementation and also could raise issues in performance,
etc. In any case, it seems like our metadata for splitting a document
into parts are not working as intended. The question is whether should
try to fix this in a future version of the web services message profile, or
whether we should simply recommend that implementers increase the maximum POST
size in their web server configurations? 2. Currently, we can
query for filings or cases by case # or date. Should we also be able to
query based on filing assembly MDE ( vendor) or filing status? 3. Can we add an
indicator to the machine-readable court policy to indicate whether filings with
multiple lead documents are supported? 4. How could ECF 3.0
be used or extended to support Judge Review and approval of documents, draft
orders, etc.? Other Questions
5. Once the TC
defines a conformance testing process, is there a source of funds available for
writing ECF conformance testing tools? Maricopa has developers who may be
interested in writing the testing tools. 6. Is anyone aware of
any code generator that can generate C# code templates for a given schema?
James E. Cabral Jr.
The
information transmitted is intended only for the person or entity to which it
is addressed and may contain confidential and/or privileged material. If you
received this in error, please contact the sender and delete the material from
any computer. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]