Electronic Court Filing 3.0 WebService Profile
Working Draft 01, September 9, 2005
Document identifier:
wd-LegalXML-WebService-Profile-01.doc
Location:
Editor:
[List your editors here; check whether “Editor” header should be plural]
Contributors:
Shane Durham, LexisNexis
Eric Tingom, eCorridor, Inc.
Tom Clarke, NationalCenter for State Courts
Scott Came, JusticeIntegration Solutions, Inc.
Dallas Powell, Tybera Development Group, Inc
James Cabral, MTG Management Consultants, LLC.
Rex McElrath, Judicial Council of Georgia
Donald Bergeron, LexisNexis
James Cusick, Wolters Kluwer
John M. Greacen, Greacen Associates, LLC
Roger Winters, KingCounty, Department of Judicial Administration
Abstract:
This document defines the Electronic Court Filing 3.0 WebService Profile, consisting of a set of non-proprietary Web services and XML specifications, along with clarifications and amendments to those specifications, which promote interoperability.
Status:
This document is a Working Group Draft and has NOT been accepted by the Working Group as reflecting but is to serve as the basis for discussions. It is a work in progress, and should not be considered authoritative or final; other documents will superseded this document.
Committee members should send comments on this specification to the list. Others should subscribe to and send comments to the mailto: list. To subscribe, send an email message to mailto:?subject=Subscribe with the word "subscribe" as the body of the message.
Table of Contents
1Introduction
1.1Notational Conventions
1.1.1Visual Indicators
1.1.2Guiding Principles
1.2Core Profile
1.2.1Web Services Description Language
1.2.2WS-Interoperability Basic Profile 1.1 provides
1.2.3WS-Interoperability Basic Security Profile 1.0
1.2.4WS-Interoperability Attachments Profile 1.0 with Soap Messages with Attachments provides
1.2.5WS-Interoperability Simple SOAP Binding Profile Version 1.0
2Web Services
2.1Filing Assembly MDE
2.1.1Filing Assembly Glossary
2.1.2Filing Assembly Overview
2.1.3Filer Review Filing Callback Service
2.2Filing Review MDE
2.2.1Filing Review Glossary
2.2.2Filing Review Overview
2.2.3Review Filing Service
2.2.4Record Docketing Callback Service
2.3Court Record MDE
2.3.1Court Record Glossary
2.3.2Court Record Overview
2.3.3Record Docketing into the Court Record Service
2.4Service MDE
2.4.1Service Glossary
2.4.2Service Overview
2.4.3Serve Filing Service
2.5Service Registry MDE
2.5.1Service Registry Glossary
2.5.2Service Registry Overview
2.5.3Get Service Registry Information
2.6Query MDE
2.6.1Query Glossary
2.6.2Query Overview
2.6.3Calculate Fees
2.6.4Case List Service
2.6.5Case Service
2.6.6Document Service
2.6.7Filing List Service
2.6.8Filing Service
2.6.9Filing Status Service
2.7Court Policy MDE
2.7.1Court Policy Glossary
2.7.2Court Policy Overview
2.7.3Court Policy Service
3References
3.1Normative
Appendix A. Acknowledgments
Appendix B. Revision History
Appendix C. Notices
1Introduction
This document is a Proposed Standard developed by the OASIS LegalXML Member Section Electronic Court Filing Technical Committee.
This document is intended to describe the information required for Electronic Court Filing 3.0 and the structure of that information. No information regarding the content of any pleading or other legal devices (e.g., contracts, orders, and judgments) is included, other than what is required to accomplish the intended task.
This specification is the product of a consensus process. Many items covered by the standard attracted valuable inputs from multiple viewpoints. The views about items were often not identical. When resolution of items needed to be reached, discussion on proposed resolutions were closed only when the question “Is there anyone cannot live with this?” was answered in the negative.
This Profile specification is to clarify any ambiguities that exist in other specifications that are used as the foundation. All of the National specifications specify that you may do this or that or you should do this, or you must do this, or you must not do this. That provides an a level reliability infrastructure so that a reliable delivery of messages. Note: Court Policy Development Time will set this message delivered once and only once, or this message gets delivered a specified number of how many times it gets delivered.
This Profile does not guarantee 100% interoperability because vendors and government agencies must agree to support what has been specified in the profile.
1.1Notational Conventions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.
This specification uses the following namespace prefixes:
NOTE: Current location needs to be updated:
Temporary -
Prefix / Namespaceecf-definitions /
xsd /
soap /
wsdl /
jxdm /
court-policy /
query /
review-filing /
case-type-information /
callback-messages /
payment /
base-message /
record-docketing /
Profile Identification and Versioning
Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH. The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the Policy. MINOR versions retain source and binary compatibility with older minor versions, and changes in the PATCH level are perfectly compatible, forwards and backwards.
One can also use this information to determine whether two instances of a profile are backwards-compatible; that is, whether one can assume that conformance to an earlier profile instance implies conformance to a later one.
1.1.1Visual Indicators
In the following sections, different fonts are used to identify the meaning of the term. Except within the Document. Type Definition (XML Schema), the font size is 8 point.
The Arial font identifies the names of elements and attributes.
A Bold font, whether in Arial or Times New Roman, is used for emphasis or to identify the beginning of adefinition.
1.1.2Guiding Principles
All of the profiles are being developed according to a set of principles that, together, form the Core Profile, as it relates to bringing about interoperability. This section documents these guidelines.
Focus profiling effort
The focus of the profile is the specifications that are explicitly defined as in-scope for the profile.
Strength of requirements
The Profile makes strong requirements (e.g., MUST, MUST NOT) wherever feasible; if there are legitimate cases where such a requirement cannot be met, conditional requirements (e.g., SHOULD, SHOULD NOT) are used. Optional and conditional requirements introduce ambiguity and mismatches between implementations.
Multiple mechanisms
If a referenced specification allows multiple mechanisms to be used interchangeably, the Profile selects those that are well understood, widely implemented and useful. Extraneous or underspecified mechanisms have been minimized to increase interoperability.
Future compatibility
When possible, the Profile aligns its requirements with in-progress revisions to the specifications it references. This aids implementers by enabling a graceful transition, and assures that WS-I does not 'fork' from these efforts. When the Profile cannot address an issue in a specification it references, this information is communicated to the appropriate body to assure its consideration.
Focus on interoperability
Although there are potentially a number of inconsistencies and design flaws in the referenced specifications, the Profile only addresses those that affect interoperability.
Conformance targets
Where possible, the Profile places requirements on artifacts (e.g., WSDL descriptions) rather than the producing or consuming software's behaviors or roles.
Lower-layer interoperability
The Profile speaks to interoperability at the web-services layer only; it assumes that interoperability of lower-layer protocols ( e.g. TCP, HTTP ) and technologies (e.g. encryption and signature algorithms ) is adequate and well-understood. WS-I does not attempt to assure the interoperability of these protocols and technologies as a whole.
Do no harm
Interoperability of technologies does not in and of itself ensure security, and the act of combining new technologies and protocols is especially susceptible to security threats. The profile takes steps to avoid introducing new security threats.
1.2Core Profile
This profile describes an implementation specification for the structure of all types of messages documented in the Use Cases and Electronic Court Filing 3.0 Specifications.
This profile provides an implementation specification for the functional requirements (Use Cases); the ECF 3.0 WebService profile provides an implementation specification for the Non Functional Requirements.
This profile will consist largely as a set of schemas, one for each type of message structure that was previously addressed in Electronic Court Filing 3.0 Specification. The schemas are based on GJXDM as much as possible.
Through the first phase of Web services adoption, eight specifications have risen to prominence as providing the basic functionality required to start developing Web services for Electronic Court Filing 3.0. The first profile proposed is ECF 3.0 Web services and is based on the following standards:
- WS-I Basic Profile Version 1.1
- WS-I Basic Security Profile Version 1.0
- WS-I Attachments Profile Version 1.0
- WS-I Simple SOAP Binding Profile Version 1.0
- XML Schema 1.0
- SOAP 1.1
- WSDL 1.1
- UDDI 2.0
The conventions and best practices associated with this Profile will be developed by one or more LegalXML Court Filing Groups.
This profile will consist largely as a set of schemas expressed has hyperlinks within major design element services, one for each type of message structure that was previously addressed in Section 1. The schemas are based on GJXDM as much as possible.
Profile Conformance
Conformance to the Profile is defined by adherence to the set of requirements defined for a specific target, within the scope of the Profile.
Conformance Requirements
All requirements in the Profile are considered normative, and those in the specifications it references that are in scope should likewise be considered normative. When requirements in the Profile and its referenced specifications contradict each other, the Profile's requirements take precedence for purposes of Profile conformance.
Definitions of terms in the Profile are considered authoritative for the purposes of determining conformance.
None of the requirements in the Profile, regardless of their conformance level, should be interpreted as limiting the ability of an otherwise conforming implementation to apply security countermeasures in response to a real or perceived threat.
Conformance Targets
Conformance targets identify what artifacts (e.g., SOAP message, WSDL description, and UDDI registry data) or parties (e.g., SOAP processor, end user) requirements apply to.
This allows for the definition of conformance in different contexts, to assure unambiguous interpretation of the applicability of requirements, and to allow conformance testing of artifacts (e.g., SOAP messages and WSDL descriptions) and the behavior of various parties to a Web service (e.g., clients and service instances).
Requirements' conformance targets are physical artifacts wherever possible, to simplify testing and avoid ambiguity.
The following conformance targets are used in the Profile:
MESSAGE - protocol elements that transport the ENVELOPE (e.g., SOAP/HTTP messages)
ENVELOPE - the serialization of the soap:Envelope element and its content
DESCRIPTION - descriptions of types, messages, interfaces and their concrete protocol and data format bindings, and the network access points associated with Web services (e.g., WSDL descriptions) (from Basic Profile 1.1)
INSTANCE - software that implements a wsdl:port or a uddi:binding Template (from Basic Profile 1.1)
SENDER - software that invokes an INSTANCE (from Basic Profile 1.1)
SENDER - software that generates a message according to the protocol(s) associated with it (from Basic Profile 1.1)
RECEIVER - software that consumes a message according to the protocol(s) associated with it (e.g., SOAP processors) (from Basic Profile 1.1)
REGDATA - registry elements that are involved in the registration and discovery of Web services (e.g. UDDI models) (from Basic Profile 1.1)
Conformance Scope
The Profile only attempts to improve interoperability within its own scope
Assumptions and Requirements
MDE operations must describe how messages are to be are addressed bysenders.
Implementations must Electronic Court Filing 3.0 specifications on messages and attachments are to be distinguished within a transmission.
A WebService profile requires messages are physically MUST be transported from a sender to an MDE via TCP/IP.
Implementations must Electronic Court Filing 3.0 specifications MUST be followed for assigning a unique identifier to each attachment. This identifier must conform to the definition of the ID data type from W3C XML Schema.
This profile provides a method when an operation is invoked on an MDE by a sender, the MDE is provides with evidence that demonstrates the identity of the sender, the content of the message(s) transmitted, and the date and time of the message transmission. (Electronic Court Filing 3.0 specifications explain identity constructs)
This profile provides a method based on WS-Interoperability standards, such that when an operation is invoked on an MDE by a sender, the MDE is able to determine if the message(s) transmitted (including any attachments) were modified during the message transmission.
This profile provides a methodthe sender MUST use to ensure that the message(s) in a transmission (including any attachments) can be processed only by the receiving MDE.
This profile provides a method the sender MUST use to include, in each message transmission, credentials that demonstrate its identity to the MDE. (Electronic Court Filing 3.0 specifications explain identity constructs)
1.2.1Web Services Description Language
The Profile uses Web Services Description Language (WSDL) to enable description of services as sets of endpoints operating on messages.
This section of the Profile incorporates the following specifications by reference, and defines extensibility points within them:
Extensible Markup Language (XML) 1.0 (Second Edition)
Namespaces in XML 1.0
XML Schema Part 1: Structures
Extensibility points:
Schema annotations - XML Schema allows for annotations, which may be used to convey additional information about data structures.
XML Schema Part 2: Data Types
Web Services Description Language (WSDL) 1.1
Extensibility points:
WSDL extensions - WSDL allows extension elements in certain places; use of such extensions requires out-of-band negotiation.
Validation mode - whether the parser used to read WSDL and XML Schema documents performs schema validation or not.
Fetching of external resources - whether the parser used to read WSDL and XML Schema documents fetches external entities and schema s. Relative URIs - WSDL does not adequately specify the use of relative URIs for the following: soapbind:body/@namespace, soapbind:address/@location, wsdl:import/@location, xsd:schema/@targetNamespace and xsd:import/@schemaLocation.
1.2.1.1Web Services Description LanguageRequired Description
An INSTANCE's WSDL 1.1 description, its UDDI binding template, or both MUST be available to an authorized SENDER upon request.
A service instance may provide run-time access to WSDL documents from a server, but is not required to do so in order to be considered conformant.
1.2.1.2Web Services Description LanguageDocument Structure
- A DESCRIPTION using the WSDL namespace (prefixed "wsdl" in this Profile) MUST be valid according to the XML Schema found at "
- A DESCRIPTION using the WSDL SOAP binding namespace (prefixed "soapbind" in this Profile) MUST be valid according to the XML Schema found at"
- A DESCRIPTION MUST only use the WSDL "import" statement to import another WSDL description. To import XML Schema Definitions, a DESCRIPTION MUST use the XML Schema "import" statement.
- A DESCRIPTION MUST use the XML Schema "import" statement only within the xsd:schema element of the types section.
- In a DESCRIPTION the schemaLocation attribute of an xsd:import element MUST NOT resolve to any document whose root element is not "schema" from the namespace
- An XML Schema directly or indirectly imported by a DESCRIPTION MAY include the Unicode Byte Order Mark (BOM).
- An XML Schema directly or indirectly imported by a DESCRIPTION MUST use either UTF-8.
- An XML Schema directly or indirectly imported by a DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C Recommendation.
- A DESCRIPTION MUST specify a non-empty location attribute on the wsdl:import element
- A DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C Recommendation.
- The targetNamespace attribute on the wsdl:definitions element of a description that is being imported MUST have same the value as the namespace attribute on the wsdl:import element in the importing DESCRIPTION.
- A DESCRIPTION containing WSDL extensions MUST NOT use them to contradict other requirements of the Profile.
- If during the processing of a description, a sender encounters a WSDL extension element that has a wsdl:required attribute with a boolean value of "true" that the sender does not understand or cannot process, the SENDER MUST fail processing.
1.2.2WS-Interoperability Basic Profile 1.1 provides
The WS-Interoperability Basic Profile 1.1 profile defines the best process and any place where it says 'must,' be followed in the Electronic Court Filing 3.0 development. Any time WS-Interoperability Basic Profile 1.1 states, 'may,' 'should,' 'may not' or 'should not,' states, 'may,' 'should,' 'may not' or 'should not,' this specification will declare the recommended Electronic Court Filing 3.0 development approach.
1.2.2.1Messaging
Revision to E0002 - Processing order - The order of processing of a SOAP envelope's components (e.g., headers) is underspecifiedand their use requires out-of-band negotiation.
Revision to E0003 - Use of intermediaries - SOAP Intermediaries is an underspecified mechanism in SOAP 1.1, and their use requires out-of-band negotiation.
1.2.2.2SOAP Envelopes
Revision to R1033 An ENVELOPE MUST NOT contain the namespace declaration xmlns:xml="
Revision to R1034 A DESCRIPTION MUST NOT contain the namespace declaration xmlns:xml="
1.2.2.3SOAP Processing Model
Revision to R1028 When a fault is generated by a RECEIVER, further processing MUST NOT be performed on the SOAP envelope aside from that which is necessary to rollback, or compensate for, any effects of processing the envelope prior to the generation of the fault.
Revision to R1030 A RECEIVER that generates a fault MUST NOT notify the end user that a fault has been generated when practical, by whatever means is deemed appropriate to the circumstance.
1.2.2.4SOAP Faults - SOAP Custom Fault Codes
Revision to R1004 When an ENVELOPE contains a faultcode element, the content of that element MUST be one of the fault codes defined in SOAP 1.1 (supplying additional information if necessary in the detail element).
Revision to R1031 When an ENVELOPE contains a faultcode element the content of that element MUST NOT use of the SOAP 1.1 "dot" notation to refine the meaning of the fault.
1.2.2.5Use of SOAP in HTTP
HTTP Protocol Binding
Revision to R1140 A MESSAGE MUST be sent using HTTP/1.1.
SOAPAction HTTP Header
Revision to R1119 A RECEIVER MUST respond with a fault if the value of the SOAPAction HTTP header field in a message is not quoted.