Comments on ECF 5.0 and a couple of questions

[Joe Mierwa <Joe.Mierwa@urlintegration.com>]

Hello,

 

As per Jim Cabral, I am posting some comments, questions and suggestions for the working draft of the ECF.

The following are comments, and in some cases, questions. All of these comments are occurring because of some consultation work we are doing for a client and our recommendation is that any filings with the courts use the ECF 5.0 (which we anticipate being in public review by the time we are finished).

 

1. GetDocumentResponseMessage structure requires the presence of a Document element. This is in contrast to GetCaseListResponseMessage and GetCaseResponseMessage which only requires a cardinality of 0. I think that Document in GetDocumentResponseMessage should have a cardinality of 0.
2. Retire the use of ecf:SendingMDELocationID and ecf:ServiceInteractionProfileCode and replace its usage with ws:addressing by defining these as part of reference parameters

Which can be added directly into the WSDL, I think. TODO: More fully analyze reference parameter usage.

3. I can’t seem to find a concise means of determining what and when the DocumentationIdentification should be used versus the DocumentFilingControlID.
4. Serve filing:
   1. My interpretation is that the actual means of electronic service delivery is implied to be present in the filing message, which would have been previously obtained from the ServiceInformationResponseInformation message. If that interpretation is correct, then the example instance is incorrect because no means of electronic service, email or any other form that could be specified.
   2. If my interpretation is correct, some clarification is needed to make the implicit explicit. Let me know and I will send you a suggestion or two for actual content to consider.
   3. If my interpretation is incorrect, then explain it to me and I can provide some text suggestions to make it clearer.
   4. An example instance of the serve filing is missing
   5. I think that all example messages except for serve filing should *not* have ecf:ElectronicServiceInformation at the top of the message.
   6. Elements ecf:ReceivingMDELocationID and ecf:ReceivingMDEProfileCode are not well defined in terms of what they represent. The value of https://eserviceprovider.com:8000 in the example kind of implies that this is an endpoint that service MDE contacts to effect the delivery of the notification. Exactly what is the purpose of these?
5. Court Policy; In reviewing the UML diagram for court policy, there appears to be inconsistency between the UML and the physical schema. Specifically, code lists in the model do not show as being related to the court extension element while they are in the schema.
6. Court Policy, the definitions for  elements  ExtensionCanonicalURI, ExtensionCanonicalVersionURI and ExtensionLocationURI in the schema and model are vague and should be much more explicit.
7. Court Policy, the definitions for  elements  ExtensionCanonicalURI, ExtensionCanonicalVersionURI and ExtensionLocationURI do not appear to be represented in the model.
8. Court Policy, CoreCodeList the model mapping of elementName in the model is shown to be mapped to ECFCanonicalURI whereas in the example instance for policyresponse:GetPolicyResponseMessage, the element name appears to be mapped to DocumentIdentification
9. Court Policy, It appears that the contextual meaning of ExtensionCanonicalURI is synonymous with ECFCanonicalURI, which I would think means that we could remove ECFCanonicalURI unless the semantic meaning needs to be much more precise, in which case the Schema and model would need to include that.
10. CourtPolicy, the reconciliation between AllowedCodeValue attributes for display text and value do not make sense in the model, especially when trying to reconcile that to the schema. Maybe it should be referring to the genericode XML instances containing that information as a note in the model?
11. Document. Section 5.2.1, ‘Court-Specific Augmentations’. And schema. CourtOrderAugmentationPoint should be added to the schema and added into the table.
12. Base Message in the model. It took me a very long time to figure this out (years in fact), but unless I am very much mistaken, the data elements at the base message level are effectively data points that would potentially be used for routing and other types of middleware capabilities. If I am wrong, please correct me. If I am right, then I have two suggestions; 1. Make that explicit in the ECF word document. 2. Investigate the movement of these data points either into a custom ECF SOAP header for the SIP or roll the majority of these data points into custom endpoint references for SOAP based SIPs and maybe using them as is for MQ or Rest based SIPs.
13. Response message mismatch between model and ResponseMessageType. The definition of response message in the schema is missing the mapping as represented by attribute queryError in the message. In other words, the sequence in ResponseMessageTpe appears to be missing a reference to element cbrn:MessageStatus.
14. Following on from #13, the cardinality requirements do not provide an adequate mapping for the mandatory elements and attributes in the MessageStatus schema (cbrn:systemSimulatedIndicator, cbrn:SystemEventDateTime and cbrn:MessageStatusCode) There appears to be some direction on the use of this in section 5.2.2, ‘Court-Specific Code Lists’, which does not seem to be the most appropriate location for it. Also, assuming that the text discussing errors is correct, the model should be expanded to split out the error into its own class that can contain more than just the single value it currently has.
15. For the GetPolicyRequestMessage, there is no meaningful discussion anywhere as to what purpose is served by the case type attribute in the schema, which should probably be located in section 6.1.1, ‘GetPolicy’