|
Title
|
Disposition
|
|
Issues
|
|
|
I-1. Package Structure
|
We have obtained the clarification necessary, so we are able to continue the Springboard test tool design & implementation.
|
|
I-2. WSDL Validation
|
The suggested revision has been addressed in the ECF v4.01 Errata 01, Working Draft 01, dated 15 October 2013.
|
|
I-3. Document Reference
|
We have obtained the clarification necessary, so we are able to continue the Springboard test tool design & implementation.
|
|
I-4. Schema Encoding
|
The suggested revision has been addressed in the ECF v4.01 Errata 01, Working Draft 01, dated 15 October 2013.
|
|
I-5. Juvenile Reference
|
The suggested revision has been addressed in the ECF v4.01 Errata 01, Working Draft 01, dated 15 October 2013.
|
|
I-6. Inconsistent WS-RM Standards
|
In lieu of any other guidance, we presume that the use of the latest specification was intended. Therefore, the Springboard project will proceed
with WS-Reliable Messaging v1.1.
|
|
I-7. Invalid Sample
|
We have obtained the clarification necessary, so we are able to continue the Springboard test tool design & implementation.
|
|
I-8. Incorrect Parameter Reference
|
In lieu of any other guidance, we presume that the parameters CoreFilingMessage and PaymentMessage are both optional.
|
|
I-9. Requirement Typo
|
In lieu of any other guidance, we presume the “typo” was correctly identified and will be resolved in a future version.
|
|
I-10. Error Handling
|
In lieu of any other guidance, we presume the ECF WS SIP will be revised to indicate the use of SOAP faults to communicate error information
between web service exchange partners. As a result, the Springboard test suite will verify success criteria based on the presence of fault conditions in the message exchange.
|
|
Observations
|
|
|
O-1. Optional Interoperability?
|
We understand that the ECF working group overtly decided that the specification should maintain maximum flexibility as a core objective of the
specification. Therefore, the Springboard project will determine a test strategy that for each optional service interaction component specification.
|
|
O-2. Must and/or May?
|
Consistent with the “O-1. Optional Interoperability?” disposition above, we understand that the intention of the specification was to convey
the service interaction components as optional.
|
|
O-3. Simplify Requirements
|
We have obtained the clarification necessary, so we are able to continue the Springboard test tool design & implementation.
|
|
O-4. Binary Encoding
|
In lieu of any other guidance, we presume the ECF Technical Working Group will update the specification to change the use
of MTOM encoding to NIEM-compliant base64 encoding, which is built into the XML specification, and provides a consistent mechanism for binary encoding and transport across all SIPs.
The binary document “attachments” will be stored using the “DocumentType” in the “ECF-4.0-CommonTypes.xsd” schema.
|
|
O-5. Substitution groups
|
We understand that the ECF Technical Working Group is unlikely to use choice instead of substitution groups. Therefore, the Springboard test
utilities will temporarily switch to Choice in order to facilitate request/response validation during testing.
|
|
O-6. GRA Reference
|
In lieu of any other guidance, we presume the intention was to use the latest specification. Therefore, the Springboard project will proceed
with the GRA Web-Services Service Interaction Profile v1.3 specification.
|
|
O-7. WS-Addressing Not Specified
|
In lieu of any other guidance, we presume the ECF Technical Working Group will update the service interaction profile to include WS-Addressing
as a mechanism to uniquely identify MDE addresses. The WS-Addressing information should be consistent with the ReceivingMDELocationID and SendingMDELocationID elements.
|