ECF 3.0 IEPD and WSDL uploaded

["Scott Came" <scott@justiceintegration.com>]

I have just uploaded a zip file containing the Court Filing 3.0 Information Exchange Package Documentation (IEPD) and
two WSDL documents that define the messaging structures for the Web Services Messaging Profile.

The basic
structure of the zip archive is as follows:

subset/ : subdirectory containing the GJXDM schema subset
ubl-1.0/ : subdirectory containing the relevant schemas from UBL
constraint-schema.xsd : constraint schema that
implements cardinality restrictions and replaces the jxdm namespace definition in the subset (jxdm.xsd)
constraint-schema-transform.xsl : stylesheet that transforms jxdm.xsd (from subset) into constraint-schema.xsd
*-extension-schema.xsd : extension schemas, defining a namespace for each message structure, utilizing constrained
GJXDM schema subset
ecf-3.0.wsdl : WSDL document defining messages, ports, and SOAP bindings for the ECF 3.0
Major Design Elements (MDEs)
sample-service-impl.wsdl : WSDL that demonstrates how to import ecf-3.0.wsdl and
define physical service endpoints for each MDE

Note that the two WSDLs allow implementations to define
their physical endpoints (which will have endpoint-specific information) without editing the core ECF 3.0 WSDL.  We
discussed this on a conference call awhile back.

Also note that I have done some factoring of the extension
namespaces...in particular:

* base-message-extension-schema.xsd containing all of the base types for the
messages themselves
* case-type-extension-schema.xsd containing some aggregation structures for the case
type-specific message structures
* common-types-extension-schema.xsd defines a namespace containing extension
types used in more than one message

As I was building the IEPD, I encountered a number of open issues that
need to be resolved before we can consider the IEPD stable.  I note these in the following list along with the name of
a TC member who I suppose might be a good candidate to follow up.  (Tom=Tom Clarke, John=John Greacen, Eric=Eric
Tingom, Jim=Jim Cabral).

1. In CriminalFiling model, Charge.chargeEnhancingAllegationTypeCode has no
definition and no code list.  It was not clear to me what this is.  I believe this was part of the Eric / Tom Clarke
mapping contribution.  This element has not been included in the IEPD.  (Tom/Eric)
2. The NCIC vehicle make and
model codes are, in most web services implementations, too big to be generated into endpoint code.  This means that
schemas that include the full code lists are not usable in toolkits like Apache Axis or the .NET tooling.  The
inclusion of all the codes also makes the IEPD large.  I did not include the enumerated values of these codelists in
the subset.  Need a decision on what to do.  (Tom/John/Eric)
3. Code list values remain undefined for: Bankruptcy
"level" elements, sendingMDEProfileCode (basically, a list of the profiles...we had talked about using some
URIs defined in the written specification), DriverAuthorizationCommercialClassCode (in extended person schema),
CaseTypeCode (in common types schema).  (Tom/John/Eric/Jim)
4. We never modeled a structure to hold public key
information in Court Policy.  Needs doing, but isn't this profile-specific?  What would we expect to be in this
structure for sneaker-net?  (Tom/John/Eric)
5. In domestic model, changed cardinality on Marriage.dateOfDivorce
and Marriage.dateOfSeparation from 1,1 to 0,1 (not all married people are divorced or separated.)   Needs
confirmation.  (John)
6. In domestic model, changed cardinality of association
DomesticCase.DomesticCaseViolencePetition from 1,1 to 0,1.  Needs confirmation. (John)
7. In queries,
BlueQueryMessage and BlueMessage seemed the same to me.  So I replaced occurrances of the former with the latter. 
Needs confirmation.  (John/Tom)
8. In queries, since query responses are synchronous, I changed all response
messages to extend MessageReceiptMessage.  Needs confirmation.  (John/Tom)
9. If #7 and #8 are ok, we should go
back and update the domain model (should take about 15 minutes.)  Changes have only been made in the schemas, not the
model or mapping spreadsheet.
10. In queries, in CalculatedFeesResponseMessage, we were using SubmissionFee to
hold the monetary amount of the fee for the filing.  However, GJXDM's SubmissionFee element does not allow for an
amount of money (it is a generic Obligation.)  So, CalculatedFeesResponseMessage now contains an element of type
AmountType to hold the fee amount.  Needs confirmation.  (John/Tom/Jim)
11. In queries, changed cardinality of
association FilingQueryResponseMessage.FilingDocuments from 1,1 to 1,*
12. In juvenile filing model, implemented
SubjectPlacement as choice between PersonPlacement and OrganizationPlacement.  I thought this was the intention, but
the mapping spreadsheet was not clear.  Needs confirmation.  (John/Jim)
13. In juvenile filing mapping, mapping
of JuvenileCase to Act was not complete in spreadsheet; assumed choice between DelinquentAct and StatusOffenseAct. 
Needs confirmation.  (John/Jim)
14. In juvenile filing, implemented DelinquentAct "code" as text. 
Needs confirmation.  (John/Jim)
15. In juvenile filing, mapped StatusOffenseActCode to StatuteType.  Needs
confirmation.  (John/Jim)
16. In review filing mapping, renamed SubmissionDocument to FilingLeadDocument.  This
introduces an extension element, but we need to do that anyway since the type of the element is in the extension
namespace.  Naming it more specifically helps the reader understand what it is.  Needs confirmation. 
(John/Tom/Eric)
17. In ReviewFiling model, extended DocumentDescriptiveMetadata by bundling extensions into a new
ExtendedDocumentDescriptiveMetadataType, since there are other places in the schemas using the jxdm version of
DocumentDescriptiveMetadataType.  Needs confirmation.  (John/Jim)
18. In ReviewFiling model, extended
CaseParticipants (to handle CaseRespondentPartyAttorney and CaseInitiatingPartyAttorney) by building these two
extensions into a new ExtendedCaseParticipantsType.  This prevents cascading extensions up through CaseType.  Needs
confirmation.  (John/Tom/Eric)
19. In ReviewFiling model, to avoid massive cascading extensions to PersonType,
remodeled and remapped the "alias" structure to be a class associated with case, with references to the
"aliased" person/organization.  The alternative is ugly with tons of extensions to PersonType and everything
that extends PersonType.  Needs confirmation.  (John/Tom/Jim/Eric)
20. In ReviewFiling model, all Case..Person
and Case..Organization associations were 1,1.  This was just sloppy modeling...should be 0,*.  Changed in model,
mapping, and schemas.  Needs confirmation.  (John/Tom/Jim/Eric)
21. In Payment model, seems
FeeExceptionReasonCode should be 0,1...there won't always be a fee exception.  Made it so in schemas and mapping
spreadsheet.  Needs confirmation.  (Jim)
22. In Juvenile mapping, changed name of extension type JuvenileCase to
JuvenileCaseInformationType, to make it consistent with names of other types.  Needs confirmation.  (John/Jim)
23. It appears to me that the ElectronicServiceInformation structure in ReviewFiling has never been completely
finished.  Shouldn't ElectronicServiceInformation be associated with ReviewFilingMessage, not
ElectronicFilingMessage?  Can RecordDocketingMessages have service attestation attached?  I also couldn't find
mappings of this structure in the spreadsheet.  **I have not included anything for ElectronicServiceInformation in the
schemas.**  (This only impacts the ReviewFiling message; the messages in the ServiceMDE and ServiceRegistryMDE have
all been implemented in schema and WSDL.)  (Jim)

In addition, here are some issues the TC needs to consider
(again, with a suggested person who might know the answer):

1.  We should consider renaming
CriminalFilingType to CriminalCaseInformationType (consistency)
2.  We should consider renaming
TrafficCitationType to TrafficCitationInformationType or TrafficCitationCaseInformationType (consistency)
3.  We
need to decide on a format for namespace identifiers for extension namespaces and WSDL namespaces.  I just chose a
pattern that made sense to me, and leans toward what I've seen done in other GJXDM IEPDs.

Finally, some
things cannot be implemented in schema, and need to be reflected in the written specification.  I include these here
as a reminder.  (Eric)

1.  Cardinality varies too much across different message structures for the same
elements in the schema subset, so the best we can do is define them as having 0..1 cardinality in the constraint
schema.  This needs to be tightened up in the written specification, e.g., where elements are required in a particular
message structure.
2.  In the Payment message structure, which uses UBL, there is one case where we want tighter
cardinality than the UBL schemas allow.  AllowanceCharge.ReasonCode is 0..1 in UBL, but we want 1..1.  This needs to
be specified in the written specification.

Finally finally, note that the WSDLs do not include mechanisms
to support implementing the non-functional requirements established by the specification.  We would need to have the
Web Services Messaging Profile defined first before we can put the implementing mechanisms in the WSDL.

I
have uploaded new versions of the domain model and mapping spreadsheet.  Since the only diagram that changed was
ReviewFiling, I have regenerated that image and uploaded it as well.  Ditto a regenerated documentation file.

I look forward to the TC's review of the IEPD and WSDLs.

Thanks.
--Scott