See Eric’s response below. He also added that:
I also wanted to add that "Amicus Briefs" are not filed on behalf of any party to the case and similarly "Opposition to summons for deposition" at the trial level.
Jim Cabral
MTG Management Consultants, L.L.C.
www.mtgmc.com
(206) 442-5010
Phone
(502) 509-4532
Mobile
Helping our clients make a difference in the lives of the people they serve.
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.
From: Eric Eastman [mailto:eric@greenfiling.com]
Sent: Wednesday, July 25, 2012 8:28 AM
To: sergueim@intresys.com
Cc: James E Cabral; legalxml-courtfiling@lists.oasis-open.org; George Knecht (george@greenfiling.com)
Subject: Re: [legalxml-courtfiling] FW: Proposed patch to ECF 4.0
Thanks for considering this.
1. I thought that 1 was the default for maxoccurs and it definitely is:
However, I'm using Java's JAXB for parsing/writing and that seems to be treating "unbounded" as the default, at least some of the time. I'll continue to research this, but I'd say that being explicit is better than relying on defaults,
especially if that gets the correct behavior out of one of the major XML tools.
Looking into the details of my other maxOccurs="unbounded" gripes, I'm finding that they are declared explicitly that way. For example, everything in PersonType and PersonNameType in niem-core are unbounded. It seems reasonable to have
a list of aliases that a person has used, but that should be a separate element (it's actually a separate case participant with a role of "AKA" or "FKA" in most systems). Every system I know about has a single main name for each person and that name can contain
only one last name.
2. I question the usefulness of having FilingAttorneyID and FilingPartyID at the document level at all. That implies that it is possible for a lead document to be filed by one attorney on behalf of one party and a connected document on
the same filing be filed by a different attorney on behalf of someone else, which I think is not the case. So those data elements belong at the filing level rather than the document. I also understand a pragmatic case against making that change.
As for the AdditionalData, this is probably going to break down along "Purist" vs. "Git r done" lines. I acknowledge the logical argument that Serguei is making. Let me make the pragmatic one:
I'm dealing with a partner who doesn't have the greatest level of XML sophistication. Creating an extension is not a good solution for us politically. I'm convincing them to use ECF for my own (somewhat selfish) reasons.
Think about from the perspective of my partner in this interface; he just wants to get his job done quickly. "So you're telling me that in these dozens of namespaces and schemas and a thousand data types that we already have, and after
we have filled in a dozen values that we don't really need so that it validates, we still have to create our own schema just to store the ServiceType?!?! Why didn't we just create our own schema to begin with?"
This guy is exactly the sort we need to be able to make a compelling case to if we want ECF adopted broadly. If something as basic and easily foreseeable as this requires an extension then every ECF deployment will need an extension and
we should include a sample extension shipped with the standard and be clear from the beginning.
One of the first people I ever build client-server applications with always included "Extra 1", "Extra 2" and "Extra 3" fields on each screen, because, if you don't, users start shoehorning the data they need into the existing fields. In
the end this is about humility, realizing that I'm not so smart that I can anticipate everything.
Thanks for your consideration,
On Tue, Jul 24, 2012 at 3:43 PM, Serguei Mysko <sergueim@intresys.com> wrote:
Hi,
I see two aspects in the proposal:
1. Cardinality: maxOccurs="1";
2. New elements: AffectedPartyID, AdditionalData
On (1):
Schema default value for occurrence is 1.
Therefore, as an example,
<xsd:element ref="ParentDocumentReference" minOccurs="0"/> as in the spec
and
<xsd:element ref="ParentDocumentReference" minOccurs="0" maxOccurs="1" /> as in the proposal
come to the very same result.
As a side remark on the subject.
I believe that in practice cardinality is quite often regulated by Court policy/business rules rather than schema spec.
A Court, for instance, may accept no more than 4 Defendants, while another Court would impose no such constraints.
On (2):
Apparently the purpose of the AffectedPartyID element is to have a list of other, somehow related parties.
Looking from the spec side (its Common Types).
Is it possible to not have other somehow related (affected in a way) parties?
- Yes.
Is it possible to not have FilingParty?
- No.
The purpose of the AdditionalData is to get a typeless (anything goes into String) bag of name/value pairs.
Looking from the spec side.
Will all or most of the implementers need a bag of typeless properties.
- A number of implementations will need a provision to specify additional properties, each with own way.
This however does not belong to Common Types.
Because we do not introduce new common type, rather a collection of generic (strings) elements.
A better solution for (2) would be to create an extension.
That would resolve the problem at hand while not affecting other implementations that do not face the same problem.
Thank you.
-
Serguei Mysko
Intresys
On 7/24/2012 7:26 AM, James E Cabral wrote:
ECF TC:
Here is a proposed patch to ECF 4.01 from Green Filing. Since these add content and constraints,
unless there is an immediate need to get these into ECF 4.01, let’s consider these for ECF 4.1.
Jim Cabral
MTG Management Consultants, L.L.C.
www.mtgmc.com
(206) 442-5010
Phone
(502) 509-4532
Mobile
Helping our clients make a difference in the lives of the people they serve.
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.
From: Eric Eastman [mailto:eric@greenfiling.com]
Sent: Tuesday, July 24, 2012 10:21 AM
To: James E Cabral
Cc: George Knecht
Subject: Proposed patch to ECF 4.0
Jim,
As you know, we have created an EFSP (FilingAssemblyMDE) for the state of Utah. This currently uses a LegalXML 1.1 (bastardized) interface to the courts. We are in the final
stages of providing a bulk filing interface to one of our existing customers using ECF 4.0.1 and have felt it necessary to extend the information in the DocumentMetadata element. Please consider the following changes to the ECF-4.0-CommonTypes.xsd file for
possible inclusion in a future release of ECF. Also let me know if there is a better way of approaching this problem that I missed. I think the annotations in the xsd code below spell out what I'm trying to do. I'd be happy to talk about it if/when you have
time.
Additionally, for a future release, there are many places where adding a maxOccurs="1" would make parsing the documents easier. The default, at least as JAXB has implemented
it is "unbounded".
[Edited section. Changes in bold.]
<xsd:complexType name="DocumentMetadataType">
<xsd:annotation>
<xsd:documentation>Document descriptors (title, type description, etc.) for the Document. This is
meant to include all the information about the document that is needed to index it into the Case
Management System and enter it into the Document Management System.</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="s:MetadataType">
<xsd:sequence>
<xsd:element ref="j:RegisterActionDescriptionText" minOccurs="0" maxOccurs="1" />
<xsd:element ref="ParentDocumentReference" minOccurs="0" maxOccurs="1" />
<xsd:element ref="PriorRelatedDocumentID" minOccurs="0" maxOccurs="1" />
<xsd:element ref="FilingAttorneyID" minOccurs="0" maxOccurs="1" />
<xsd:element ref="FilingPartyID" minOccurs="0" maxOccurs="1" />
<xsd:element ref="AffectedPartyID" minOccurs="0" maxOccurs="unbounded" />
<xsd:element ref="SpecialHandlingInstructions" minOccurs="0" maxOccurs="1" />
<xsd:element ref="RedactionRequiredIndicator" minOccurs="0" maxOccurs="1" />
<xsd:element ref="AdditionalData" maxOccurs="unbounded" minOccurs="0" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="AffectedPartyID" type="nc:IdentificationType">
<xsd:annotation>
<xsd:documentation>ID recognized by the court as being unique within this case,and used to identify a party who will be affected by filing this document (eg. which party was served by a return of service).</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="AdditionalDataType">
<xsd:attribute name="name" type="xsd:string"></xsd:attribute>
<xsd:attribute name="value" type="xsd:string"></xsd:attribute>
</xsd:complexType>
<xsd:element name="AdditionalData" type="AdditionalDataType">
<xsd:annotation>
<xsd:documentation>Any additional information that needs to be passed along with the document. This might include the method of service for a Return of Service or the amount of a Judgement.</xsd:documentation>
</xsd:annotation>
</xsd:element>
--
Eric Dimick Eastman
Green Filing, LLC
--
Eric Dimick Eastman
Green Filing, LLC