€¦ · web viewdocument structure - wsdl and schema import. revision to r2009 an xml schema...

Electronic Court Filing 3.0 WebService ProfileWorking Draft 01, September 9, 2005Document identifier:

document.doc

Location:http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/

Editor:[List your editors here; check whether “Editor” header should be plural]

Contributors:Shane Durham, LexisNexisEric Tingom, eCorridor, Inc.Tom Clarke, National Center for State CourtsScott Came, Justice Integration Solutions, Inc.Dallas Powell, Tybera Development Group, IncJames Cabral, MTG Management Consultants, LLC.Rex McElrath, Judicial Council of GeorgiaDonald Bergeron, LexisNexisJames Cusick, Wolters KluwerJohn M. Greacen, Greacen Associates, LLCRoger Winters, King County, 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 [email protected] list. Others should subscribe to and send comments to the mailto:[email protected] list. To subscribe, send an email message to mailto:[email protected]?subject=Subscribe with the word "subscribe" as the body of the message.

document.doc 12-Sep-2005

Copyright © OASIS Open 2005. All Rights Reserved of 32

1

2

3

4

56

78

910

11121314151617181920212223

242526

27282930

313233

1

2

mailto:[email protected]?subject=Subscribe

mailto:[email protected]

mailto:[email protected]

http://www.oasis-open.org/spectools/docs/

Table of Contents1 Introduction 4

1.1 Notational Conventions 41.1.1 Visual Indicators 51.1.2 Guiding Principles 5

1.2 Core Profile 51.2.1 Web Services Description Language 71.2.2 WS-Interoperability Basic Profile 1.1 provides 71.2.3 WS-Interoperability Basic Security Profile 1.0 101.2.4 WS-Interoperability Attachments Profile 1.0 with Soap Messages with Attachments provides 111.2.5 WS-Interoperability Simple SOAP Binding Profile Version 1.012

2 Web Services 132.1 Filing Assembly MDE 13

2.1.1 Filing Assembly Glossary 132.1.2 Filing Assembly Overview 132.1.3 Filer Review Filing Callback Service 14

2.2 Filing Review MDE 152.2.1 Filing Review Glossary 152.2.2 Filing Review Overview 152.2.3 Review Filing Service 152.2.4 Record Docketing Callback Service 16

2.3 Court Record MDE 172.3.1 Court Record Glossary 172.3.2 Court Record Overview 172.3.3 Record Docketing into the Court Record Service 17

2.4 Service MDE 182.4.1 Service Glossary 182.4.2 Service Overview 182.4.3 Serve Filing Service18

2.5 Service Registry MDE 192.5.1 Service Registry Glossary 192.5.2 Service Registry Overview 192.5.3 Get Service Registry Information 19

2.6 Query MDE 202.6.1 Query Glossary 202.6.2 Query Overview 212.6.3 Calculate Fees 212.6.4 Case List Service 212.6.5 Case Service 222.6.6 Document Service 232.6.7 Filing List Service 232.6.8 Filing Service 242.6.9 Filing Status Service 25

2.7 Court Policy MDE 262.7.1 Court Policy Glossary 262.7.2 Court Policy Overview 262.7.3 Court Policy Service 26

3 References 273.1 Normative 27



34

35

363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283

3

4

Appendix A. Acknowledgments 28Appendix B. Revision History 30Appendix C. Notices 31



848586

87

5

6

1 IntroductionThis 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.1 Notational 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 - http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/3.0/service-definitions

Prefix Namespace

ecf-definitions http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/3.0/service-definitions

xsd http://www.w3.org/2001/XMLSchema

soap http://schemas.xmlsoap.org/wsdl/soap

wsdl http://schemas.xmlsoap.org/wsdl

jxdm http://www.it.ojp.gov/jxdm/3.0.2

court-policy http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/3.0/court-policy

query http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/3.0/query

review-filing http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/3.0/review-filing

case-type-information http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/3.0/case-type-information

callback-messages http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/3.0/callback-messages

payment http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/3.0/payment

base-message http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/3.0/base-message

record-docketing http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/3.0/record-docketing

Profile Identification and VersioningVersions 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.



8889

909192

939495

96979899

100101

102103104

105106

107

108

109110

111112113

114115

7

8

1.1.1 Visual IndicatorsIn 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 a definition.

1.1.2 Guiding 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.2 Core ProfileThis 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



116117118

119

120

121122123

124

125

126

127128129

130

131132133

134

135136137138

139

140141

142

143144

145

146147148

149

150151

152153154

155156

157158

159160161

162

163

164

165

166

9

10

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 ConformanceConformance to the Profile is defined by adherence to the set of requirements defined for a specific target, within the scope of the Profile.

Conformance RequirementsAll 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 TargetsConformance 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 ScopeThe Profile only attempts to improve interoperability within its own scope

Assumptions and RequirementsMDE operations must describe how messages are to be are addressed by senders.

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.



167

168

169

170

171172

173174

175176

177

178179180

181

182183

184

185186

187188189

190

191

192

193

194195

196

197

198

199200

201202

203204

205

206207

208

209210

211

212213

214

11

12

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 method the 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.1 Web Services Description LanguageThe 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.1 Web Services Description Language Required DescriptionAn 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.2 Web Services Description Language Document Structure A DESCRIPTION using the WSDL namespace (prefixed "wsdl" in this Profile) MUST be valid according to the XML Schema

found at "http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd".

A DESCRIPTION using the WSDL SOAP binding namespace (prefixed "soapbind" in this Profile) MUST be valid according to the XML Schema found at"http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd".

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.



215216217

218219220

221222

223224

225226

227

228

229

230

231

232

233

234

235

236

237

238239240

241242

243244

245246247

248249

250251

252

253254

255

256

257258

259

260

261262

263

13

14

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.2 WS-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.1 MessagingRevision to E0002 - Processing order - The order of processing of a SOAP envelope's components (e.g., headers) is underspecified and 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.2 SOAP EnvelopesRevision to R1033 An ENVELOPE MUST NOT contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace".

Revision to R1034 A DESCRIPTION MUST NOT contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace".

1.2.2.3 SOAP 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.4 SOAP Faults - SOAP Custom Fault CodesRevision 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.5 Use of SOAP in HTTPHTTP Protocol Binding

Revision to R1140 A MESSAGE MUST be sent using HTTP/1.1.

SOAPAction HTTP HeaderRevision to R1119 A RECEIVER MUST respond with a fault if the value of the SOAPAction HTTP header field in a message is not quoted.

HTTP Success Status CodesRevision to R1111 An INSTANCE MUST use a "200 OK" HTTP status code on a response message that contains an envelope that is not a fault.

Revision to R1112 An INSTANCE MUST use either a "200 OK" or "202 Accepted" HTTP status code for a response message that does not contain a SOAP envelope but indicates the successful outcome of a HTTP request.

HTTP Redirect Status CodesRevision to R1131 A CONSUMER MUST automatically redirect a request when it encounters a "307 Temporary Redirect" HTTP status code in a response.

HTTP Client Error Status CodesRevision to R1113 An INSTANCE MUST use a "400 Bad Request" HTTP status code, if a HTTP request message is malformed.

Revision to R1114 An INSTANCE MUST use a "405 Method not Allowed" HTTP status code if a HTTP request message's method is not "POST".



264265

266267268269

270271272

273274

275276277

278279

280281282283

284285

286287288

289290

291292

293

294

295296

297

298299

300301

302

303304

305

306

307308

15

16

R1115 An INSTANCE MUST use a "415 Unsupported Media Type" HTTP status code if a HTTP request message's Content-Type header field-value is not permitted by its WSDL description.

1.2.2.6 Service DescriptionExtensibility points:

Revision to E0017 - Schema annotations - XML Schema allows for annotations, which MUST NOT be used to convey additional information about data structures.

Document Structure - WSDL and Schema ImportRevision to R2009 An XML Schema directly or indirectly imported by a DESCRIPTION MUST include the Unicode Byte Order Mark (BOM).

Document Structure - WSDL Import location Attribute SemanticsRevision to R2008 A CONSUMER MUST retrieve a WSDL description from the URI specified in the location attribute on a wsdl:import element.

Document Structure - XML Namespace declarationsRevision to R4005 A DESCRIPTION MUST NOT contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace".

Document Structure - WSDL and the Unicode BOMRevision to R4002 A DESCRIPTION MUST include the Unicode Byte Order Mark (BOM).

Document Structure - WSDL documentation ElementRevision to R2030 In a DESCRIPTION the wsdl:documentation element MUST be present as the first child element of wsdl:import, wsdl:part and wsdl:definitions in addition to the elements cited in the WSDL1.1 specification.

Document Structure - WSDL ExtensionsRevision to R2026 A DESCRIPTION MUST NOT include extension elements with a wsdl:required attribute value of "true" on any WSDL construct (wsdl:binding, wsdl:portType, wsdl:message, wsdl:types or wsdl:import) that claims conformance to the Profile.

1.2.2.7 Typessoapenc:Array

Revision to R2112 In a DESCRIPTION, elements MUST NOT be named using the convention ArrayOfXXX.

WSDL and Schema Definition Target NamespacesRevision to R2114 The target namespace for WSDL definitions and the target namespace for schema definitions in a DESCRIPTION MUST be the same.

1.2.2.8 MessagesBindings and Parts

Revision to R2209 A wsdl:binding in a DESCRIPTION MUST bind every wsdl:part of a wsdl:message in the wsdl:portType to which it refers with a binding extension element.

Revision to R2202 A wsdl:binding in a DESCRIPTION MUST contain soapbind:body element(s) that specify that zero parts form the soap:Body.

Revision to R2207 A wsdl:message in a DESCRIPTION MUST contain wsdl:parts that use the elements attribute provided those wsdl:parts are not referred to by a soapbind:body in an rpc-literal binding.

Revision to R2208 A binding in a DESCRIPTION MUST contain soapbind:header element(s) that refer to wsdl:parts in the same wsdl:message that are referred to by its soapbind:body element(s).

1.2.2.9 Port TypesOrdering of part Elements

Revision to R2302 A DESCRIPTION MUST use the parameterOrder attribute of an wsdl:operation element to indicate the return value and method signatures as a hint to code generators.

1.2.2.10 SOAP BindingMultiple Bindings for portType Elements



309310

311312

313314

315

316317

318

319320

321

322323

324

325

326

327328

329

330331

332333

334

335

336337

338339

340341

342343

344345

346347

348349

350351

352353

17

18

Revision to R2709 A wsdl:portType in a DESCRIPTION MUST have zero or more wsdl:bindings that refer to it, defined in the same or other WSDL documents.

Multiple Ports on an EndpointRevision to R2711 A DESCRIPTION MUST NOT have more than one wsdl:port with the same value for the location attribute of the soapbind:address element.

Describing headerfault ElementsRevision to R2719 A wsdl:binding in a DESCRIPTION MUST contain no soapbind:headerfault elements if there are no known header faults.

Enumeration of FaultsRevision to R2740 A wsdl:binding in a DESCRIPTION MUST contain a soapbind:fault describing each known fault.

Revision to R2741 A wsdl:binding in a DESCRIPTION MUST contain a soapbind:headerfault describing each known header fault.

Revision to R2742 An ENVELOPE MUST contain fault with a detail element that is not described by a soapbind:fault element in the corresponding WSDL description.

Revision to R2743 An ENVELOPE MUST contain the details of a header processing related fault in a SOAP header block that is not described by a soapbind:headerfault element in the corresponding WSDL description.

Omission of the use AttributeRevision to R2722 A wsdl:binding in a DESCRIPTION MUST specify the use attribute on contained soapbind:fault elements.

Consistency of Envelopes with DescriptionsRevision to R2724 If an INSTANCE receives an envelope that is inconsistent with its WSDL description, it MUST generate a soap:Fault with a faultcode of "Client", unless a "MustUnderstand" or "VersionMismatch" fault is generated.

Allowing Undescribed HeadersRevision to R2739 An ENVELOPE MUST NOT contain SOAP header blocks that are not described in the wsdl:binding that describes it.

Revision to R2753 An ENVELOPE containing SOAP header blocks that are not described in the appropriate wsdl:binding MUST NOT have the mustUnderstand attribute on such SOAP header blocks set to '1'.

Ordering HeadersRevision to R2752 An ENVELOPE MUST contain more than one instance of each SOAP header block for each soapbind:header element in the appropriate child of soapbind:binding in the corresponding description.

1.2.2.11Use of XML SchemaRevision to R2800 A DESCRIPTION MUST use the construct from XML Schema 1.0.

1.2.3 WS-Interoperability Basic Security Profile 1.0 The WS-Interoperability Basic Security Profile Version 1.0 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 Security Profile Version 1.0 states, 'may,' 'should,' 'may not' or 'should not,' this specification will declare the recommended Electronic Court Filing 3.0 development approach.

1.2.3.1 SOAP Message Security Revision to E0002 - Security Tokens - Security tokens MUST be specified in additional security token profiles. (NOTE: This will be determined in Court Policy)

SecurityTokenReferences - Direct Preferred to Embedded for Internal ReferencesRevision to R3023 Each SECURITY_TOKEN_REFERENCE that refers to an INTERNAL_SECURITY_TOKEN that is referenced several times MUST be a direct reference rather than an embedded reference.

1.2.3.2 X.509 Certificate Token ProfileToken Types - Certificate Path Format

Revision to R5202 When certificate path information is provided, a SENDER MUST provide the X509PKIPathv1 token type.

1.2.3.3 XML-SignatureGeneral Constraints on XML Signature - Signature Types



354355

356

357358

359

360361

362

363

364

365366

367368

369

370

371

372373

374

375376

377378

379

380381

382383

384385386387

388389390

391

392393

394395

396

397398

19

20

Revision to R3103 A SIGNATURE MUST be a Detached Signature as defined by the XML Signature specification.

Revision to R3104 A SIGNATURE MUST NOT be an Enveloped Signature as defined by the XML Signature Specification.

Element References in XML Signature - Reference to Elements by Shorthand XPointer (XMLDSIG)

Revision to R3005 When a ds:Reference/@URI in a SIGNATURE is a Shorthand XPointer Reference to an element not defined by XML Signature or XML Encryption, the reference value SHOULD be a wsu:Id.

XML Encryption Syntax - Reference to Elements by Shorthand XPointer (XMLENC)Revision to R5611 When an xenc:DataReference/@URI or xenc:KeyReference/@URI in an ENCRYPTION_REFERENCE_LIST is a Shorthand XPointer Reference to an element not defined by XML Signature or XML Encryption, the reference value MUST be a wsu:Id.

Revision to R5612 When an xenc:DataReference/@URI or xenc:KeyReference/@URI in an ENCRYPTED_KEY_REFERENCE_LIST is a Shorthand XPointer Reference to an element not defined by XML Signature or XML Encryption, the reference value MUST be a wsu:Id.

1.2.3.4 Relationship of Basic Security Profile as an Extension to Basic ProfileBasic Profile Clarifications - BP Requirement R2724

bp11:R2724 states "If an INSTANCE receives an envelope that is inconsistent with its WSDL description, it SHOULD generate a soap:Fault with a faultcode of 'Client', unless a 'MustUnderstand' or 'VersionMismatch' fault is generated."

Revision to R5807 For bp11:R2724 "Inconsistent" MUST be taken to mean "Inconsistent after SOAP Message security has been reversed", for the ENVELOPE

Basic Profile Clarifications - BP Requirement R1029Revision to R5814 Where the normal outcome of processing a SECURE_ENVELOPE would have resulted in the transmission of a SOAP Response, but rather a fault is generated instead, a RECEIVER MUST transmit a fault about the message.

1.2.3.5 Security ConsiderationsSecurity Token Substitution

Revision to C5440 When the signer's SECURITY_TOKEN is an INTERNAL_SECURITY_TOKEN, the SIGNATURE MUST include a ds:Reference that refers to the signer's SECURITY_TOKEN in order to prevent substitution with another SECURITY_TOKEN that uses the same key.

Revision to C5441 When the signer's SECURITY_TOKEN is an EXTERNAL_SECURITY_TOKEN, the SIGNATURE MUST include a ds:Reference that refers to the SECURITY_TOKEN_REFERENCE that refers to the signer's SECURITY_TOKEN using the Security Token Dereferencing Transform in order to prevent substitution of another SECURITY_TOKEN that uses the same key

Replay of Username TokenRevision to C4210 Any SECURITY_TOKEN named wsse:UsernameToken that contains a wsse:Nonce element and a wsse:Password element with a Type attribute value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText" MUST be referenced by a ds:Reference in a SIGNATURE in order to prevent replay.

Revision to C4211 Any SECURITY_TOKEN named wsse:UsernameToken that contains a wsu:Created element and a wsse:Password element with a Type attribute value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText" MUST be referenced by a ds:Reference in a SIGNATURE in order to prevent replay.

1.2.4 WS-Interoperability Attachments Profile 1.0 with Soap Messages with Attachments provides

The WS-Interoperability Attachments Profile 1.0 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 Attachments Profile 1.0 states, 'may,' 'should,' 'may not' or 'should not,' this specification will declare the recommended Electronic Court Filing 3.0 development approach.

1.2.4.1 Attachments PackagingEncoding of Root Part

Revision to R2915 The entity body of the root part of a multipart/related MESSAGE MUST be serialized using UTF-8 character encoding.

Revision to R2916 Non-root parts of a multipart/related MESSAGE MUST use UTF-8 character encoding.

Dereferencing Attachments



399

400

401402

403404

405

406407408

409410411

412413

414415

416417

418

419420

421422

423424425

426427428

429

430431432

433434435

436437438439440

441442

443444

445

446

21

22

Revision to R2918 A RECEIVER MAY ignore a URI reference to an attachment in an envelope. NOTE: Refer to Court for Development Time Policy.

Carrying Additional SOAP EnvelopesRevision to R2919 A MESSAGE MUST BE ABLE TO contain soap:Envelopes carried as attachments in parts that are not the root part of the message. NOTE: Refer to Court for Development Time Policy.

Fault Messages with AttachmentsRevision to R2920 An INSTANCE MUST send a fault with attachments if and only if the wsdl:output element is described using the WSDL MIME binding.

Ordering of MIME PartsRevision to R2929 A MESSAGE MUST have its MIME parts in any order provided that the identity of the root part is maintained.

1.2.4.2 Attachments DescriptionUnbound portType Element Contents

Revision to R2941 A wsdl:binding in a DESCRIPTION MUST bind every wsdl:part of a wsdl:message in the wsdl:portType to which it refers to one of soapbind:body, soapbind:header, soapbind:fault , soapbind:headerfault, or mime:content

Referencing Attachments from the SOAP EnvelopeRevision to R2940 In a DESCRIPTION, a wsdl:part defined with the ref:swaRef schema type MUST only be bound to a soapbind:body, or a soapbind:header in a MIME binding.

Specifying SOAP Headers in Root PartRevision to R2905 The soapbind:header element in a DESCRIPTION MAY be included as a child of the mime:part element.

Ordering of PartsRevision to R2947 In a DESRIPTION, a mime:part element that contains a soapbind:body child element MUST appear in a position amongst the other child elements of a mime:multipartRelated element.

Sending Fault MessagesRevision to R2913 A Fault MESSAGE MUST be serialized as either text/xml or multipart/related, if the wsdl:output child element of the corresponding binding operation in a description has a child mime:multipartRelated element.

Sending Additional Parts Not Described in WSDLRevision to R2923 A SENDER MUST send non-root MIME parts not described in the WSDL MIME binding. NOTE: Refer to Court for Development Time Policy.

1.2.4.3 Document Size and FormatDocuments being filed along with (or as part of) messages can be of specified size. (NOTE: Refer to Court for Development Time Policy.) Documents can also be in any of following formats:

Microsoft Word

WordPerfect

PDF

TIFF

MIME and DIME

RTF

TEXT

XML

1.2.5 WS-Interoperability Simple SOAP Binding Profile Version 1.0The WS-Interoperability Simple SOAP Binding Profile Version 1.0 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 Simple SOAP Binding Profile Version 1.0 states, 'may,' 'should,' 'may not' or 'should not,' this specification will declare the recommended Electronic Court Filing 3.0 development approach.

1.2.5.1 MessagingXML Namespace declarations

Revision to R9704 An ENVELOPE MUST NOT contain the namespace declaration xmlns:xml="http://www.w3.org/XML/1998/namespace".



447448

449

450451

452

453454

455

456

457458

459460

461

462463

464

465

466

467468

469

470471

472

473474

475476477

478

479

480

481

482

483

484

485

486487488489

490491

492493

23

24

1.2.5.2 DescriptionBindings - Unbound portType Element Contents

Revision to R2209 A wsdl:binding in a DESCRIPTION MUST bind every wsdl:part of a wsdl:message in the wsdl:portType to which it refers to one of soapbind:body, soapbind:header, soapbind:fault or soapbind:headerfault.



494495

496497

498

25

26

2 Web Services

2.1 Filing Assembly MDEThe Filing Assembly MDE supports the preparation and submission of filings to a court for review and can receive the results of that process.

This Process represents the Filer’s side of the electronic filing of documents and Filing Metadata submitted to the court electronically by means of an XML based protocol.

This Process provides an interface to human Filers to a court for review, to receive responses to those filings, and to submit requests to a Court for information and to receive responses to those requests.

A Filing Assembly MDE will often be tightly coupled with other LegalXML system Processes and third-party Processes.

A Filing MDE may be provided by a court or by a third party.

2.1.1 Filing Assembly GlossaryTerm Description

Filing Electronic document collection that has been assembled for filing on a designated court case.

Docketing The process invoked when a court receives a pleading, order, or notice, when no errors in transmission or in

presence of required content have occurred, and when the pleading, order, or notice is recorded as a part of the

official record.

Document Represents a electronic version of the paper that would have been sent as paper.

Filer Attorneys or pro se litigants are individuals who assemble and submit Filings (data and documents)

2.1.2 Filing Assembly Overview Usage Scenario

Synchronous Request/Response

Basic Callback

One Way



499

500

501

502503

504505

506507

508

509

510

511512

513

514

515

27

28

2.1.3 Filer Review Filing Callback ServiceOperations/Message Types

Operation Msg. Type

Message Parameters Type

NotifyFilingReviewComplete Input NotifyFilingReviewCompleteRequest

FilingReviewResults callback-messages:ReviewFilingCallbackMessageType

CaseTypeSpecificInformation case-type-information:CaseTypeSpecificInformationType

CourtSpecificInformation xsd:anyType

CaseInformation case-type-information:CaseInformationType

PaymentReceipt payment:FilingPayment

output NotifyFilingReviewCompleteResponse

2.1.3.1 NotifyFilingReviewCompleteDescriptionA call to this operation results in the Filing Review MDE sending a request back regarding the Filing Review Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the filing message in the final request/response. The NotifyFilingReviewCompleteRequest includes the FilingReviewResults, CaseTypeSpecificInformation, CourtSpecificInformation, CaseInformation, and optional PaymentReceipt.

ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.

Message StyleThe rpc/literal message style will be used.

2.1.3.2 WSDL The Notify Review Filing Callback Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.

WSDL Note: The address will need to be updated with a permanent address.

Temporary Address:

http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip

SchemaNote: The address will need to be updated with a permanent address.

Temporary Address:




516517

518519

520521522523

524

525

526

527

528529530

531

532

533

534

535

536

537

538

29

30



2.2 Filing Review MDEThe Filing Review MDE receives, presents, and manages the filings. When the Filing Review MDE receives filings in a standard format/structure and presents those filings to a Clerk for review, where they may be accepted or rejected.

The Filing Review MDE transmits data and documents to the Filing Assembly MDE to inform the Filer that the Filing has been accepted or rejected.

For accepted filings, the Filing Review MDE transmits data and documents to the Court Record MDE for Docketing recording of the documents.

2.2.1 Filing Review GlossaryTerm Description

Filing The set of electronic documents and associated metadata included in a submission intended to be docketed by the court. This document or collection of documents is either accepted or rejected by the court. It should be noted that, in some courts, “filing” means acceptance of a packet of associated documents. “Filing” is understood as opposed to “docketing,” which is the recording in a docket or register of actions of a filing, event, or activity that the court makes part of its official record

Docketing The process invoked when a court receives a pleading, order, or notice, when no errors in transmission or in presence of required content have occurred, and when the pleading, order, or notice is recorded as a part of the official record.

Document An XML document instance. One or more electronic pleadings or other court devices that can be contained within an XML document or XML envelope.


2.2.2 Filing Review Overview Usage Scenario


Basic Callback

One Way

2.2.3 Review Filing ServiceOperations/Message Types

Operation Msg. Type Message Parameters Type

ReviewFiling Input ReviewFilingRequest Corefiling review-filing:ReviewFilingMessageType

CaseTypeSpecificInformation

case-type-information:CaseTypeSpecificInformationType


FilingPayment payment:FilingPayment

output ReviewFilingResponse

2.2.3.1 ReviewFiling DescriptionThe Filing Review MDE sends a Filing Receipt, expressing the filing was accepted, and that the documents and other data were recorded into the court record.

A call to this operation results in the Filing Review MDE processing a request regarding the Filing Review Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the review filing message in the final request/response. The ReviewFilingRequest includes the Corefiling, CaseTypeSpecificInformation, CourtSpecificInformation, and optional FilingPayment.





539540541

542543

544545

546

547548

549

550

551

552553

554555

556557

558559560561

562

563

564

565

31

32

2.2.3.2 WSDL The Review Filing Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


2.2.4 Record Docketing Callback ServiceOperations/Message Types

Operation Msg. Type


NotifyDocketingComplete Input NotifyDocketingCompleteRequest RecordDocketingMessage record-docketing:RecordDocketingMessageType



CaseInformation case-type-information:CaseInformationType

output NotifyDocketingCompleteResponse

2.2.4.1 NotifyDocketingComplete DescriptionThe Filing Review MDE receives a Record Docketing Callback, expressing the filing was docketed, and that the documents and other data were recorded into the court record.

A call to this operation results in the Filing Review MDE processing a callback regarding the Record Docketing Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the notify docketing complete message in the final request/response. The NotifyDocketingCompleteRequest includes the RecordDocketingMessage, CaseTypeSpecificInformation, CourtSpecificInformation, and CaseInformation.



2.2.4.2 WSDL The Record Docketing Callback Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:




566567

568

569

570

571

572

573

574

575

576577

578579

580581

582583584585

586

587

588

589

590591592

593

594

595

596

597

598

599

600

601

33

34





2.3 Court Record MDEThe Court Record MDE receives, presents, and manages the filings for recording into the record. When the Court Record MDE receives filings in a standard format/structure and presents those filings to a Clerk for docketing, where they may be accepted or rejected.

The Court Record MDE transmits data and documents to the Filing Review MDE to inform the reviewer that the Filing has been accepted or rejected.

For docketed filings, the Court Record MDE transmits data and documents to the Filing Review MDE for notification of the filing’s documents have been docketed.

2.3.1 Court Record GlossaryTerm Description

Clerk Receives, indexes, and files pleadings, orders, and notices for litigants, attorneys, judges, and clerk of court. Reviews queued entries prior to docketing. Reviews pleadings, orders, and notices of individual case.




2.3.2 Court Record Overview Usage Scenario


Basic Callback

One Way

2.3.3 Record Docketing into the Court Record ServiceOperations/Message Types

Operation Msg. Type Message Parameters Type

RecordFiling Input RecordFilingRequest RecordDocketingMessage record-docketing:RecordDocketingMessageType

Corefiling review-filing:ReviewFilingMessageType

CaseTypeSpecificInformation

case-type-information:CaseTypeSpecificInformationType


output RecordFilingResponse

2.3.3.1 RecordFiling DescriptionThe Court Record MDE receives a Record Filing, expressing the filing is to be docketed, and that the documents and other data are ready to be processed into the court record.

A call to this operation results in the Court Record MDE processing a message regarding the Record Docketing Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the record filing message in the final request/response. The NotifyDocketingCompleteRequest includes the RecordDocketingMessage, Corefiling, CaseTypeSpecificInformation, and CourtSpecificInformation.





602603604

605606

607608

609

610611

612

613

614

615616

617618

619620

621622623624

625

626

627

628

35

36

2.3.3.2 WSDL The Record Docketing Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


2.4 Service MDEThe Service MDE enables a filer or a court to transmit filings to other parties who are participating in the case electronically who are entitled to copies of the filing.

The Service MDE transmits data and documents to the Filing Assembly MDE to inform the case participant that the Filing has been made with the court.

For docketed filings, the Service MDE transmits data and documents only to the Filing Assembly MDE for notification to the case participant.

2.4.1 Service GlossaryTerm Description

Service The performance of secondary service is notification to a case participant that a filing has been made.

Court An official, lawful authority to adjudicate disputes, and to dispense civil, labor, administrative and criminal justice under the law.



Case Participant May be any person for whom a court wishes to establish a substantive communication because of his/her importance to the case.

2.4.2 Service Overview Usage Scenario


Basic Callback

One Way

2.4.3 Serve Filing ServiceOperations/Message Types

Operation Msg. Type


Servefiling Input ServefilingRequest Corefiling review-filing:ReviewFilingMessageType



output ServefilingResponse

2.4.3.1 Servefiling Description



629630

631

632

633

634

635

636

637

638

639640641

642643

644

645

646647

648

649

650

651652

653654

37

38



The Service MDE receives a Filing for service, expressing the filing is to be served, and that the documents and other data are ready to be processed.

A call to this operation results in the Serve MDE processing a message regarding the Filing Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the serve filing message in the final request/response. The ServefilingRequest includes the Corefiling, CaseTypeSpecificInformation, and CourtSpecificInformation.



2.4.3.2 WSDL The Serve Filing Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


2.5 Service Registry MDEThe Service Registry MDE enables a filer or court to obtain the electronic and/or mail addresses of all parties in a case that must be served..

The Service Registry MDE transmits service address information to the Filing Assembly MDE to inform the filer for whom he/she may serve electronically.

The Service Registry MDE transmits data about know case participants service information for a specific case.

2.5.1 Service Registry GlossaryTerm Description

Service The performance of secondary service is notification to a case participant that a filing has been made.





2.5.2 Service Registry Overview Usage Scenario


Basic Callback

One Way

2.5.3 Get Service Registry InformationOperations/Message Types

Operation Msg. Type




655656

657658659

660

661

662

663

664665

666

667

668

669

670

671

672

673

674675

676677

678

679

680681

682

683

684

685686

39

40



GetServiceInformation Input GetServiceInformationRequest ServiceInformationQueryMessage query:ServiceInformationQueryMessageType

output GetServiceInformationResponse

2.5.3.1 GetServiceInformation DescriptionThe Service MDE receives a Filing for service, expressing the filing is to be served, and that the documents and other data are ready to be processed.

A call to this operation results in the Serve MDE processing a message regarding the Filing Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the serve registry information message in the final request/response. The ServefilingRequest includes the Corefiling, CaseTypeSpecificInformation, and CourtSpecificInformation.



2.5.3.2 WSDL The Get Service Registry Information Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


2.6 Query MDEThe Query enables a court to provide inquiry and response to other parties about case and related filing information.

The Query MDE transmits data and documents to the Filing Assembly MDE to inform the requesting MDE the requested information.

For accepted queries, the Query MDE transmits data and documents to the Filing Assembly MDE.

2.6.1 Query GlossaryTerm Description





Clerk Receives, indexes, and files pleadings, orders, and notices for litigants, attorneys, judges, and clerk of court. Reviews queued entries prior to docketing. Reviews pleadings, orders, and notices of individual case.





687688

689690

691692693

694

695

696

697

698

699700701

702

703

704

705

706

707

708

709

710711

712

713

714

41

42



2.6.2 Query Overview Usage Scenario


2.6.3 Calculate FeesOperations/Message Types

Operation Msg. Type


GetCalculatedFee Input GetCalculatedFeesRequest CalculatedFeesQueryMessage

query:CalculatedFeesQueryMessageType

output GetCalculatedFeesResponse

2.6.3.1 GetCalculatedFee DescriptionThe Query MDE receives a Filing for fee calculation, expressing the filing’s lead document, supporting documents, and other date are ready to be used in calculating filing fees.

A call to this operation results in the Query MDE processing a message regarding the Calculate Fee Message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the serve filing message in the final request/response. The GetCalculatedFeesRequest includes the CalculatedFeesQueryMessage.



2.6.3.2 WSDL The Calculate Fees Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


2.6.4 Case List ServiceOperations/Message Types

Operation Msg. Type


GetCaseList Input GetCaseListRequest CaseListQueryMessage query:CaseListQueryMessageType

output GetCaseListResponse

2.6.4.1 GetCaseList DescriptionThe Query MDE receives a request for to query the courts records for a list of cases based on provided criteria.



715716

717

718719

720721

722723

724725726

727

728

729

730

731732

733

734

735

736

737

738

739

740

741

742743

744745

746

43

44



A call to this operation results in the Query MDE processing a message regarding the list of cases meeting the case list criteria message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the case list message in the final request/response. The GetCaseList includes the CaseListQueryMessage.



2.6.4.2 WSDL The Case List Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


2.6.5

2.6.6 Case ServiceOperations/Message Types

Operation Msg. Type


GetCase Input GetCaseRequest CaseQueryMessage query:CaseQueryMessageType

output GetCaseResponse

2.6.6.1 GetCaseDescriptionThe Query MDE receives a request for to query the courts records for a case based on provided criteria.

A call to this operation results in the Query MDE processing a message regarding the case meeting the case criteria message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the case message in the final request/response. The GetCase includes the CaseQueryMessage.



2.6.6.2 WSDL The Case Service Fees Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:





747748749

750751

752

753

754

755756

757

758

759

760

761

762

763

764

765

766767

768769

770

771772773

774775

776

777

778

779780

781

782

783

784

785

786

45

46




Temporary Address:


2.6.7 Document ServiceOperations/Message Types

Operation Msg. Type


GetDocument Input GetDocumentRequest DocumentQueryMessage query:DocumentQueryMessageType

output GetDocumentResponse

2.6.7.1 GetDocumentDescriptionThe Query MDE receives a request for to query the courts records for a case’s document based on provided criteria.

A call to this operation results in the Query MDE processing a message regarding the document meeting the document criteria message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the document message in the final request/response. The GetDocument includes the DocumentQueryMessage.



2.6.7.2 WSDL The Document Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


2.6.8 Filing List ServiceOperations/Message Types

Operation Msg. Type


GetFilingList Input GetFilingListRequest FilingListQueryMessage query:FilingListQueryMessageType

output GetFilingListResponse

2.6.8.1 GetFilingListDescriptionThe Query MDE receives a request for to query the courts records for a list of filings based on provided criteria.

A call to this operation results in the Query MDE processing a message regarding the filing list meeting the filing and case criteria message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the filing list message in the final request/response. The GetFilingList includes the FilingListQueryMessage.



787

788

789

790

791792

793794

795

796797798

799800

801

802

803

804805

806

807

808

809

810

811

812

813

814815

816817

818

819820821

47

48






2.6.8.2 WSDL The Filing List Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:


2.6.9 Filing ServiceOperations/Message Types

Operation Msg. Type


GetFiling Input GetFilingRequest FilingQueryMessage query:FilingQueryMessageType

output GetFilingResponse

2.6.9.1 GetFilingDescriptionThe Query MDE receives a request for to query the courts records for a case’s filing based on provided criteria.

A call to this operation results in the Query MDE processing a message regarding a filing meeting the filing and case criteria message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the filing message in the final request/response. The GetFiling includes the FilingQueryMessage.



2.6.9.2 WSDL The Filing Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:




822

823

824

825

826827

828

829

830

831

832

833

834

835

836837

838839

840

841842843

844845

846

847

848

849850

851

852

853

854

855

856

857

858

49

50





2.6.10

2.6.11Filing Status ServiceOperations/Message Types

Operation Msg. Type


GetFilingStatus Input GetFilingStatusRequest FilingStatusQueryMessage query:FilingStatusQueryMessageType

output GetFilingStatusResponse

2.6.11.1GetFilingStatusDescriptionThe Query MDE receives a request for to query the courts records for a case’s filing status based on provided criteria.

A call to this operation results in the Query MDE processing a message regarding a filing status meeting the filing and case criteria message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the filing status message in the final request/response. The GetFilingStatus includes the FilingStatusQueryMessage.



2.6.11.2WSDL The Filing Status Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:




859

860861

862863

864

865866867

868869

870

871

872

873874

875

876

877

878

879

880

881

882

883

884

51

52



2.7 Court Policy MDEThe Court Policy MDE receives, presents, and manages the machine readable policies. When the Court Policy MDE receives a request in a standard format/structure and presents those policies back to the requesting MDE.

The Court Policy MDE transmits data and documents to the requesting MDE to inform the requestor that the policies and code values.

2.7.1 Court Policy GlossaryTerm Description

Machine Readable Policies Expressed as XML message and structure symbolizing the development time information (court rules governing electronic filing that are needed at the time an application is developed but which is not likely to change [e.g., whether a court will accept the filing of a URL in lieu of the document itself]), and run time information (information that will be updated from time to time [such as lists of acceptable document types, criminal charges, and civil causes of action])

2.7.2 Court Policy Overview Usage Scenario

Asynchronous Request/Response

2.7.3 Court Policy ServiceOperations/Message Types

Operation Msg. Type


GetPolicy Input GetPolicyRequest CourtID jxdm:IDType

output GetPolicyResponse

2.7.3.1 GetPolicyDescriptionThe Court Policy MDE receives a request for to query the courts machine readable policies based on provided criteria.

A call to this operation results in the Court Policy MDE processing a message regarding a policy meeting the courts policy message sent. The message header contains the correlation, message and MDE identifier to be retained by the system for sending the court policy message in the final request/response. The GetPolicyRequest includes the CourtID.



2.7.3.2 WSDL The Court Policy Service is defined by schemas and WSDL document. The schemas are imported into the types section of the WSDL.


Temporary Address:



Temporary Address:




885886887

888

889

890891

892

893894

895

896897

898

899900901

902

903

904

905

906907

908

909

910

911

912

913

914

915

916

53

54



3 References3.1 Normative

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[dateTime] N. Freed, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/xmlschema-2/#dateTime, W3C REC-xmlschema-2, October 2004.

[FIPS 180-2] National Institute for Standards and Technology, Secure Hash Standard, http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf, August 2002.

[namespaces] T. Bray, Namespaces in XML, http://www.w3.org/TR/REC-xml-names/, W3C REC-xml-names-19990114, January 1999.

[RFC2046] N. Freed, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, http://www.ietf.org/rfc/rfc2046.txt, IETF RFC 2046, November 1996.

[RFC4122] Leach, et al., A Universally Unique IDentifier (UUID) URN Namespace, http://www.ietf.org/rfc/rfc4122.txt, IETF RFC 4112, July 2005.

[XML 1.0] T. Bray, Extensible Markup Language (XML) 1.0 (Third Edition), http://www.w3.org/TR/REC-xml/, W3C REC-XML-20040204, February 2004.

[XMLSIG] Eastlake, D., Reagle, J. and Solo, D. (editors), XML-Signature Syntax and Processing, http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/, W3C Recommendation, February 2002.

[XMLENC] Eastlake, D. and Reagle, J. (editors), XML Encryption Syntax and Processing, http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/, W3C Recommendation, December 2002.



917

918919920921922923924925926927928929930931932

933934

935936

55

56

http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/

http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/

http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

http://www.w3.org/TR/REC-xml/

http://www.ietf.org/rfc/rfc4122.txt


http://www.w3.org/TR/REC-xml-names/

http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf

http://www.w3.org/TR/xmlschema-2/#dateTime


Appendix A. AcknowledgmentsThe following individuals were members of the committee during the development of this specification:

Greacen, John

Brooks, Rex

Hagler, Franklin

Roth, David

Harris, Jim

Perry, Ellen

Ensign, Chet

Bergeron, Donald

Schumacher, Scott

Goodwin, David

Gibson, Robin

Gilliam, Charles

Powell, Dallas

Poindexter, Gary

Taylor, Steven

Bousquin, Terry

Aerts, John

Johnson, Jerry

Smith, Christopher

Messing, John

O'Brien, Robert

Leff, Laurence

Rutkowski, Tony

Ruegg, John

DeFilippis, Robert

Clarke, Tom

March, Robert

Keane, James

Midstokke, Brad

Barlow, Jeff

Pope, Nick

Durham, Christopher

Slosberg, Mark

O'Day, Dan

Cover, Robin

Cabral, James

Clark, Jim

Smith, T

Welsh, D

Webster, Larry

Dillon, Ann

Wagner, Winfield

Kasselman, Pieter

Karotkin, Jeff



937

938

939

940

941

942

943

944

945

946

947

948

949

950

951

952

953

954

955

956

957

958

959

960

961

962

963

964

965

966

967

968

969

970

971

972

973

974

975

976

977

978

979

980

981

982

57

58

Martin, Roger

Plummer, Catherine

Tingom, Eric

Winters, Roger

Waite, Mike

Jensen, Allen

Clark, James Bryce

Chambers, Rolly

Cusick, James

Snowdon, Kyle

McElrath, Rex

Came, Scott

Fiore, Steven

Rutter, Nancy

Harrop, Jason

Morgan, Rockie

Cameron, Ockert

Oldenburg, Mark

Baker, Richard

Carlson, Tom

Sweeney, Ann

Sawka, Dan

Edson, Scott

Naidoo, Shogan

Beard, Jim

Alpert, Jed



983

984

985

986

987

988

989

990

991

992

993

994

995

996

997

998

999

1000

1001

1002

1003

1004

1005

1006

1007

1008

59

60

Appendix B. Revision HistoryRev Date By Whom What

wd-01 2005-09-12 Eric Tingom Initial version



1009

1010

61

62

Appendix C. NoticesOASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

Copyright © OASIS Open 2002. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



1011

101210131014101510161017

10181019

1020

102110221023102410251026

1027

102810291030

63

64