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

legalxml-courtfiling message