1) Any Filing Review Message whether it is for case
initiation or for existing case update must be able to include multiple
"Documents".
2) Each "Document" within the Filing
Review Message must be able to have court specific XML data associated with
it.
3) Each "Attachment" must be able to have court
specific XML data associated with it. (The challenge with this area is that some
courts do not define all documents as docketed items, yet these documents carry
case data that may be used to automate processes.)
4) Each "Attachment" may (must not sure of )
be assoicated to a "Document".
5) Each "Document" may have multiple "Attachments" associated to it.
6) When a "Document" is larger than a court specific size it must be broken
down into multiple parts. LegalXML Blue should define how the multiple
parts are associated with the first portion of the "Document" and they can be
included as "Documents" if the court dockets each portion in the case history or
as "Attachments" if the court does not docket each portion. This example
points to an example of why "Attachment" specific data needs XML data associated
with it to identify which part in the series it represents.
7) Regarding the Return Response Message, we must have a status at the
Filing Review Message level and at each "Document" level. I am not sure of
the "Attachment" level yet, however I can see that it may be an issue in the
future.
8) There is information that is general case information and there is
information that is document specific. Party information can be argued as
either depending on the situation, and we must be able to carry that information
in both the main body and document specific area.
9) We must have the ability to understand the condition of when a party is
being added, and when a party is being updated.
10) Some Filing Review Messages may not contain "Documents" or
"Attachments".
I support John Greacen's position that we must be able to carry any
court specific data a court needs for automation on case initiation. I
also support the same position for existing case update. What good is a
standard that allows for some automation but not everything a court really
wants. This would simply put the courts in a position where they will wait
for a standard that works for them and deviate from the limited
standard. That is one of the challenges we already face.
I struggle with the debate over whether to create a method of extending the
XML data within the main SOAP Body or whether to keep the main body simple and
straight forward. I lean towards the complete separation which is cleaner
to manage in interoperability but may not be as fast in processing because you
have to extract the XML data out of a MIME embedded attachment. This
however leads to the next definition and requirement:
Embedded Processing Data - Some form of
machine interpreted data, possibly an XML document instance, that is not
associated with any specific "Document" or "Attachment" but is general data
associated with the case, whether the data is for case initiation or for
existing case update.
11) The main Body must be able to identify this type of data and possibly
the format associated with this data.