Serguei makes some great points. For these questions, we need to continue to weigh the flexibility in allowing courts to customize these constraints in Court policy with the potential advantages in interoperability and lower complexity
in locking it down.
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: legalxml-courtfiling@lists.oasis-open.org [mailto:legalxml-courtfiling@lists.oasis-open.org]
On Behalf Of Serguei Mysko
Sent: Tuesday, July 24, 2012 3:44 PM
To: James E Cabral; Eric Dimick Eastman (eric@greenfiling.com)
Cc: legalxml-courtfiling@lists.oasis-open.org; George Knecht (george@greenfiling.com)
Subject: Re: [legalxml-courtfiling] FW: Proposed patch to ECF 4.0
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
--------------------------------------------------------------------- To unsubscribe, e-mail:
legalxml-courtfiling-unsubscribe@lists.oasis-open.org For additional commands, e-mail:
legalxml-courtfiling-help@lists.oasis-open.org