€¦ · Web viewDocument Structure - WSDL and Schema Import. Revision to R2009 An XML Schema...
Transcript of €¦ · 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 Page 1 of 32
1
2
3
4
56
78
910
11121314151617181920212223
242526
27282930
313233
1
2
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
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 2 of 32
34
35
363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283
3
4
Appendix A. Acknowledgments 28Appendix B. Revision History 30Appendix C. Notices 31
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 3 of 32
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.
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 4 of 32
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
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 5 of 32
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.
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 6 of 32
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.
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 7 of 32
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".
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 8 of 32
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
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 9 of 32
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
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 10 of 32
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
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 11 of 32
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
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".
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 12 of 32
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.
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 13 of 32
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
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 14 of 32
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 15 of 32
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.
Filer Attorneys or pro se litigants are individuals who assemble and submit Filings (data and documents)
2.2.2 Filing Review Overview Usage Scenario
Synchronous Request/Response
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
CourtSpecificInformation xsd:anyType
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.
ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.
Message StyleThe rpc/literal message style will be used.
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 16 of 32
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.
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
2.2.4 Record Docketing Callback ServiceOperations/Message Types
Operation Msg. Type
Message Parameters Type
NotifyDocketingComplete Input NotifyDocketingCompleteRequest RecordDocketingMessage record-docketing:RecordDocketingMessageType
CaseTypeSpecificInformation case-type-information:CaseTypeSpecificInformationType
CourtSpecificInformation xsd:anyType
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.
ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.
Message StyleThe rpc/literal message style will be used.
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.
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 17 of 32
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.
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.3.2 Court Record Overview Usage Scenario
Synchronous Request/Response
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
CourtSpecificInformation xsd:anyType
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.
ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.
Message StyleThe rpc/literal message style will be used.
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 18 of 32
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.
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
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.
Filer Attorneys or pro se litigants are individuals who assemble and submit Filings (data and documents)
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
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
Synchronous Request/Response
Basic Callback
One Way
2.4.3 Serve Filing ServiceOperations/Message Types
Operation Msg. Type
Message Parameters Type
Servefiling Input ServefilingRequest Corefiling review-filing:ReviewFilingMessageType
CaseTypeSpecificInformation case-type-information:CaseTypeSpecificInformationType
CourtSpecificInformation xsd:anyType
output ServefilingResponse
2.4.3.1 Servefiling Description
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 19 of 32
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.
ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.
Message StyleThe rpc/literal message style will be used.
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.
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
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.
Court An official, lawful authority to adjudicate disputes, and to dispense civil, labor, administrative and criminal justice under the law.
Filer Attorneys or pro se litigants are individuals who assemble and submit Filings (data and documents)
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
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.5.2 Service Registry Overview Usage Scenario
Synchronous Request/Response
Basic Callback
One Way
2.5.3 Get Service Registry InformationOperations/Message Types
Operation Msg. Type
Message Parameters Type
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 20 of 32
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.
ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.
Message StyleThe rpc/literal message style will be used.
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.
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
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
Court An official, lawful authority to adjudicate disputes, and to dispense civil, labor, administrative and criminal justice under the law.
Filer Attorneys or pro se litigants are individuals who assemble and submit Filings (data and documents)
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
Case Participant May be any person for whom a court wishes to establish a substantive communication because of his/her importance to the case.
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.
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.
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 21 of 32
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
Synchronous Request/Response
2.6.3 Calculate FeesOperations/Message Types
Operation Msg. Type
Message Parameters 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.
ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.
Message StyleThe rpc/literal message style will be used.
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.
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
2.6.4 Case List ServiceOperations/Message Types
Operation Msg. Type
Message Parameters 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.
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 22 of 32
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.
ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.
Message StyleThe rpc/literal message style will be used.
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.
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
2.6.5
2.6.6 Case ServiceOperations/Message Types
Operation Msg. Type
Message Parameters 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.
ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.
Message StyleThe rpc/literal message style will be used.
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.
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.
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 23 of 32
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
2.6.7 Document ServiceOperations/Message Types
Operation Msg. Type
Message Parameters 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.
ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.
Message StyleThe rpc/literal message style will be used.
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.
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
2.6.8 Filing List ServiceOperations/Message Types
Operation Msg. Type
Message Parameters 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.
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 24 of 32
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
ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.
Message StyleThe rpc/literal message style will be used.
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.
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
2.6.9 Filing ServiceOperations/Message Types
Operation Msg. Type
Message Parameters 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.
ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.
Message StyleThe rpc/literal message style will be used.
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.
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 25 of 32
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
Message Parameters 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.
ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.
Message StyleThe rpc/literal message style will be used.
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.
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 26 of 32
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
Message Parameters 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.
ScenarioThe scenario used will be Synchronous Request/Response using SOAP over HTTP.
Message StyleThe rpc/literal message style will be used.
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.
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:
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/14356/ecf-3.0-iepd-wsdl-0.2.zip
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 27 of 32
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.
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 28 of 32
917
918919920921922923924925926927928929930931932
933934
935936
55
56
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
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 29 of 32
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
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 30 of 32
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
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 31 of 32
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.
document.doc 12-Sep-2005
Copyright © OASIS Open 2005. All Rights Reserved Page 32 of 32
1011
101210131014101510161017
10181019
1020
102110221023102410251026
1027
102810291030
63
64