Re: Further Issues with os ECF 4.01

[James E Cabral <jec@mtgmc.com>]

Gary,

Appendix G (Revision History) to the core specification does indicate that some constraints were modified around the time of the time of CSPRD01/CSPRD02 although it is not specific about which constraints changed.  We need to remember that the schemas and the main bodies of the specification document are normative.  The appendices (including Appendix G) and the Change Log.doc file are non-normative and meeting minutes have often been incomplete with regard to specific changes to the specification.

At this point several years later, it is impossible for me to say conclusively that the change from maxOccurs from  (0,unbounded) to (0,1) to many of the constraints was intentional  or unintentional.  What I know is that, since 2011, there have been a number of draft versions and public reviews, approval as an OASIS standard, implementations of ECF 4.x by several companies in their solutions and the development by the IJIS Institute of a testbed for certifying conformance with the ECF 4.01 OASIS Standard.  It isn’t clear to me that we would want to change those constraints but even if the TC wanted to make that change, my personal opinion is that it would create a hardship for those who have implemented the affected versions of the specification over the last 3 years.  I would much prefer we have this discussion in the context of going forward and ECF 5.0.

I would very much like to hear from other members of the TC on this topic.

--
Jim Cabral
502-509-4532

From: Gary Graham
Sent: ‎Wednesday‎, ‎March‎ ‎26‎, ‎2014 ‎7‎:‎08‎ ‎PM
To: James E Cabral, legalxml-courtfiling@lists.oasis-open.org

With regards to CaseParticipantRoleCode, it is not my intention to suggest that these constraints have been revised since ecf 4,0.  I only mentioned CaseParticipantRoleCode as an example of the difficulties that we have experienced in opening up upper bound cardinality limitations.  Perhaps expanding this cardinality is a consideration for the next ecf version.

 

From the revision worksheet you attached, it appears that the DocumentType cardinality change occurred with 4.01 CSPRD02 on 8/9/2011.

 

In the ‘Approved Work Products’ folder under the Documents tab on the ECF web page, the document titled ‘Electronic Court Filing v4.01 CSPRD02’ (a ZIP file) (see  https://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download/.php/43732/ecf-spec-v4.01-csprd02.zip ), provided by Chet Ensign on 2011-10-01, contains ‘Change Log.doc’.  This Change Log does not describe the cardinality changes to DocumentType.

 

Although there is not any change log file contained within the CSPRD03 zip file, one is available separately asecf-v4.01-csprd03-change-list.txt ( https://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/47471/ecf-v4.01-scprd03-change-list.txt )  within the Specifications folder. This log also does not identify any changes to the DocumentType sub-element  maxOccurs.

 

I have also reviewed all the meeting minutes within this time frame and cannot find anything related to these changes. Is it possible that this maxOccurs change was just an unfortunate error that occurred between CSPRD01 and CSPRD02?

 

Provided that these revisions were just an error, is there more to the ‘squeeze’ that just identifying the correction in the Errata document?

 

From: James E Cabral [mailto:jec@mtgmc.com]
Sent: Wednesday, March 26, 2014 1:46 PM
To: Graham, Gary; legalxml-courtfiling@lists.oasis-open.org
Subject: Re: Further Issues with os ECF 4.01

 

Gary,

 

I looked at the cardinality in all the published versions of the specification since ECF 4.0 cd01. See the attached worksheet.  In short, there were several changes to constraints in ECF 4.01 CSPRD01, CSPRD02 and CSPRD03. 

 

In regards to the constraints on the elements within DocumentType, they have not changed since 2011.

 

As to CaseParticipantsRole, I don’t have evidence that those constaints have ever changed.  I’m not sure why you need to create an additional role code when you probably could have just re-used the CaseParticipant element.

 

Your recommendation to change most constraints back to 0, unbounded should not be taken lightly.  If adopted, this would revert ECF 4.01 to several versions back and prior to most public and OASIS reviews.  I’m not sure if and how this level of change would be handled through an errata process. Do you think the juice is worth the squeeze?

 

--
Jim Cabral
502-509-4532

 

From: Gary Graham
Sent: ‎Wednesday‎, ‎March‎ ‎26‎, ‎2014 ‎1‎:‎16‎ ‎PM
To: James E Cabral, legalxml-courtfiling@lists.oasis-open.org

 

I would be interested in seeing the revision history regarding constraint changes.

 

‘Overly inclusive and optional’ has been a long standing ECF principle. This suggests that absent any strong rational to the contrary, the upper limit should be unbounded.  Any implementer wanting to tighten these constraints can do so using constraint schema. It is not possible to go the other way and open up the constraints, such as setting the upper limit to unbounded, using constraint schema since messages must be valid for both ECF schema and constraint schema.

 

In Arizona, we experienced this first hand when needing to allow multiple CaseParticipantRoleCodes for a CaseParticipant (which has a maxOccurs of 1 in ECF). We could not accommodate this with either constraint schema or an extension schema using substitution; we were forced to define a new CaseParticipantRoleCode in an extension namespace.

 

Implementers may have already designed and implemented e-filing systems that leverage the ability to include multiple instances of an element type within an element of type DocumentType. In Arizona for example, we use multiple instances of DocumentIdentification within the CoreFilingMessage (note that CoreFilingMessage is of CoreFilingMessageType which is derived from ecf:ElectronicMessageType, which is derived from ecf:CaseFilingType which in turn is derived from nc:DocumentType).

 

I cannot know what other implementers may have elected to use multiple instances of other DocumentType child elements. As such, I alone cannot identify any or all that are obviously wrong.

 

My recommendation is to return all these element cardinalities back to ECF 4.0 maxOccurs of unbounded (except any that the TC specifically approved to be further constrained).

 

 

Gary Graham

 

From: James E Cabral [mailto:jec@mtgmc.com]
Sent: Wednesday, March 26, 2014 9:26 AM
To: Graham, Gary; legalxml-courtfiling@lists.oasis-open.org
Subject: Re: Further Issues with os ECF 4.01

 

Gary,

 

From the Revision History, it appears that we have made tweaks since ECF 4.0 including some changes to constraints. 

 

I guess the question should be:   Before we publish the errata, do you see any constraints that are obviously wrong?

 

--
Jim Cabral
502-509-4532

 

From: Gary Graham
Sent: ‎Wednesday‎, ‎March‎ ‎26‎, ‎2014 ‎12‎:‎09‎ ‎PM
To: James E Cabral, legalxml-courtfiling@lists.oasis-open.org

 

Jim,

 

I apologize for the delay in getting back to you on this, but I was out of town and only just returned this morning.

 

The XMLSpy diagrams were only provided to help make the issue more visibly apparent. You are correct about the XMLSpy method of displaying cardinalities of (0,1) –in this case it is with a dashed lined box with a single border. When the minOccurs is unbounded there are a pair of borders, as if stacked.

 

My point is that the content of the xsd files has changed.

 

With ECF4.0, the niem-core.xsd file ( \xsd\constraint\Subset\niem\niem-core\2.0\ ) contains the following:

 

                        <xsd:complexType name="DocumentType">

                                                <xsd:annotation>

                                                                        <xsd:documentation>A data type for a paper or electronic document.</xsd:documentation>

                                                                        <xsd:appinfo>

                                                                                                <i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/>

                                                                        </xsd:appinfo>

                                                </xsd:annotation>

                                                <xsd:complexContent>

                                                                        <xsd:extension base="s:ComplexObjectType">

                                                                                                <xsd:sequence>

                                                                                                                        <xsd:element ref="nc:DocumentApplicationName" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentBinary" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentDescriptionText" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentEffectiveDate" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentFileControlID" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentFiledDate" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentIdentification" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentInformationCutOffDate" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentPostDate" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentReceivedDate" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentSequenceID" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentStatus" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentLanguage" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentSubmitter" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                </xsd:sequence>

                                                                        </xsd:extension>

                                                </xsd:complexContent>

                        </xsd:complexType>

 

All elements within DocumentType are unbounded.

 

In the same niem-core.xsd file from ECF4.01, the following is contained:

 

                        <xsd:complexType name="DocumentType">

                                                <xsd:complexContent>

                                                                        <xsd:extension base="s:ComplexObjectType">

                                                                                                <xsd:sequence>

                                                                                                                        <xsd:element ref="nc:DocumentApplicationName" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentBinary" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentCategoryText" minOccurs="0" maxOccurs="unbounded"/>

                                                                                                                        <xsd:element ref="nc:DocumentDescriptionText" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentEffectiveDate" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentFileControlID" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentFiledDate" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentIdentification" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentInformationCutOffDate" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentPostDate" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentReceivedDate" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentSequenceID" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentStatus" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentTitleText" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentLanguage" minOccurs="0" maxOccurs="1"/>

                                                                                                                        <xsd:element ref="nc:DocumentSubmitter" minOccurs="0" maxOccurs="1"/>

                                                                                                </xsd:sequence>

                                                                        </xsd:extension>

                                                </xsd:complexContent>

                        </xsd:complexType>

 

Although the element lists are the same, in the ECF 4.01 version, all the maxOccurs are now 1 and not unbounded (except for DocumentCategoryText).

 

Gary Graham

 

 

 

From: James E Cabral [mailto:jec@mtgmc.com]
Sent: Monday, March 17, 2014 8:37 AM
To: Graham, Gary; legalxml-courtfiling@lists.oasis-open.org
Subject: Re: Further Issues with os ECF 4.01

 

Gary,

 

I looked at those schemas directly and, to meat least,  the cardinalities appear correct.  Most of the elements in the NIEM DocumentType are cardinality (0,1) - minoccurs=0 and maxoccurs=1.  It appears that, by default, XMLSpy does not show cardinalities of (0,1).    Please verify before I repost the errata document for another vote.

 

  thanks,

--
Jim Cabral
502-509-4532

 

From: Gary Graham
Sent: ‎Friday‎, ‎March‎ ‎14‎, ‎2014 ‎9‎:‎05‎ ‎PM
To: James E Cabral, legalxml-courtfiling@lists.oasis-open.org

 

More ECF 4.01 Problems

 

There appears to be a problem with the niem-core.xsd distributed with os-ECF-4.01 (e.g. the OASIS standard).

 

You can see the problem in this screen capture using XMLSpy to display the CoreFilingMessageType:

 

 

Notice that there are no cardinalities (i.e. minOccurs, maxOccurs) for the elements.

 

This should appear as shown below from ECF 4.0:

 

 

The problem appears to be in the niem-core.xsd file distributed with ECF-4.01.

 

Here is the relevant section of this file as relates to the illustration above:

 

 

 

And here is how it appears from ECF 4.0:

 

 

Gary Graham