<?xml version="1.0" encoding="UTF-8"?>
<!--
     Electronic Court Filing Version 5.01
     Committee Specification Draft 01
     23 May 2022
     Copyright (c) OASIS Open 2022. All Rights Reserved.
     Source: https://docs.oasis-open.org/legalxml-courtfiling/ecf/v5.01/csd01/examples/
     Latest version of narrative specification: https://docs.oasis-open.org/legalxml-courtfiling/ecf/v5.01/ecf-v5.01.html
     TC IPR Statement: https://www.oasis-open.org/committees/legalxml-courtfiling/ipr.php
-->
<!--
	appellate-NOA-004-RecordDocketingResponse-00.xml

	This xml example is from a series of examples that illustrate a full life cycle sequence use case for a illustration of  
	Barabara Holmes' Test Case # 1300 (Case Initiation, Court of Appeal, Appeal of an Agency determination). In this use case, 
	an attorney for the petitioner is appealing a decision from an executive branch agency (i.e. the Corporation Commission) to 
	an intermediary appellate court. 

	This example message is synchronously returned to the FAMDE by the FRMDE upon receipt of appellate-NOA-003-RecordDocketingRequest-00.xml.

	Gary Graham
	Arizona Supreme Court
	September 27, 2018. 


-->
<wrapper:ReviewFilingResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:structures="http://release.niem.gov/niem/structures/4.0/" xmlns:nc="http://release.niem.gov/niem/niem-core/4.0/" xmlns:j="http://release.niem.gov/niem/domains/jxdm/6.1/" xmlns:wrapper="https://docs.oasis-open.org/legalxml-courtfiling/ns/v5.01/wrappers" xsi:schemaLocation="https://docs.oasis-open.org/legalxml-courtfiling/ns/v5.01/wrappers ../schema/wrappers.xsd">

	<cbrn:MessageStatus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:structures="http://release.niem.gov/niem/structures/4.0/" xmlns:nc="http://release.niem.gov/niem/niem-core/4.0/" xmlns:ecf="https://docs.oasis-open.org/legalxml-courtfiling/ns/v5.01/ecf" xmlns:j="http://release.niem.gov/niem/domains/jxdm/6.1/" xmlns:cbrn="http://release.niem.gov/niem/domains/cbrn/4.1/" xsi:schemaLocation="http://release.niem.gov/niem/domains/cbrn/4.1/ ../schema/niem/domains/cbrn/4.1/cbrn.xsd http://release.niem.gov/niem/niem-core/4.0/ ../schema/niem/niem-core/4.0/niem-core.xsd https://docs.oasis-open.org/legalxml-courtfiling/ns/v5.01/ecf ../schema/ecf.xsd" cbrn:systemSimulatedIndicator="false">
	
		<!-- Date/Time the Request was received by CRMDE. -->
		<cbrn:SystemEventDateTime>2017-03-13T16:57:56.000-07:00</cbrn:SystemEventDateTime>
		
		<!-- A code for a system operating mode. Values must come from cbrncl.xsd -->		
		<!-- A validation is being performed on this element enforcing one of the following required values: -->
		<!-- 'Exercise', 'Ops', 'Other', 'Test', 'Unknown' -->
		<!--
			 "Exercise"	- The system is in use by an exercise.
			 "Ops"		- The system is in live operational use.
			 "Other"	- The system is in an unspecified operating mode. A description of this model needs to be 
						  provided in the element SystemOperatingModeText.
			 "Test"		- The system is in test operations.
			 "Unknown"	- The operating mode of the system is unknown.
		-->
		<cbrn:SystemOperatingModeCode>Ops</cbrn:SystemOperatingModeCode>
		
		<!-- A verification of the authenticating credentials -->
		<!-- Two chocies are available: 'Authenticated' and 'Not Authenticated' (see cbrncl.xsd)-->
		<!--
			"Authenticated"		- The credentials have been authenticated.
			"Not Authenticated"	- The credentials have not been authenticated.
		-->
		<!-- When and how should these be used ? 
			 Since credential authentication is not passed from the FAMDE to the FRMDE on the RvFR, then presumably this
			 element identifies whether credentials were authenticated by the FRMDE in this example.  
		-->
		<!-- The credentials are presumed to be the RvFR submitter credentials. -->
		<!-- This element is required and must be used. -->
		<cbrn:CredentialsAuthenticatedCode>Authenticated</cbrn:CredentialsAuthenticatedCode>
		
		<!-- A code for the receiving status of a message.-->
		<!-- A required enuerated list contains: 'ActivityCodeFailure', 'DeviceError', 'DuplicateMessage', -->
		<!-- 'ErrorAcknowledgment', 'InvalidSchema', 'MessageError', 'Other', 'Success', 'SystemError', 'UnknownError' -->
		
		<!-- Where are definitions for the conditions provided in the enuerated list ? Ans: see cbrncl.xsd -->
		<!--
			"ActivityCodeFailure"	- The message was successfully received by not successfully processed due to an activity code error.
			"DataError"				- The message was successfully received by not successfully processed due to a data error.
			"DeviceError"			- The message was successfully received by not successfully processed due to a device error.
			"DuplicateMessage"		- The message was successfully received but not processed since it is a duplicate of a message already processed.
			"ErrorAcknowledgement"	- Acknowledgement of receipt of an error message.
			"InvalidSchema"			- The message was received, but was not successfully processed due to an invalid schema.
			"MessageError"			- The message was received, but was not successfully processed due to an invalid message error (invalid Message Type, encoding, format, etc.)
			"Other"					- The message status does not fit any known category.
			"Success"				- The message was sucessfully received and accepted.
			"SystemError"			- The message was successfully received by not successfully processed due to a system error.
			"UnknownError"			- The message was not successfully received and/or processed due to an unknown error.
		-->
		<cbrn:MessageStatusCode>Success</cbrn:MessageStatusCode>
		
		<!-- A set of information about the point in the XML payload where an error occurred processing the message. -->
		
		<!-- Upon review by an ECF TC work group, by consensus, it was agreed that, since in this use case example there was 
			 not any XML content error, then the cbrn:MessageContentError element should be absent -->
		<!-- element commented out
		<cbrn:MessageContentError>
			<cbrn:ErrorNodeName>wrapper:ReviewFilingRequest</cbrn:ErrorNodeName>
			<cbrn:ErrorDescription>
				<cbrn:ErrorCodeText>0</cbrn:ErrorCodeText>	
			</cbrn:ErrorDescription>
		</cbrn:MessageContentError>
		-->
		<!-- Also See section 4.5 Error Handling -->
		<!-- Should there be multiple cbrn:MessageContentError elements for each ECF message (e.g. filing:FilingMessage & payment:PaymentMessage)
			  when there are XML errors in each message within the RvFR ? -->

		<!-- Unlike cbrn:MessageContentError (above), cbrn:MessageHandlingError is required; therefore it is included and reports success. -->
		<cbrn:MessageHandlingError>
			<cbrn:ErrorCodeText>0</cbrn:ErrorCodeText>
			<cbrn:ErrorCodeDescriptionText>Success</cbrn:ErrorCodeDescriptionText>
		</cbrn:MessageHandlingError>
		
		<!-- Although not clarified in the specification, it is presumed, that an ECF 5 conformant implementation 
			 IS NOT REQUIRED to resend even when resend is requested. -->
		<cbrn:ResendRequestIndicator>false</cbrn:ResendRequestIndicator>
		
		<ecf:MessageStatusAugmentation>
		
			<!-- ecf:ServiceRecipientID is provided for the response from the ServeFiling operation. -->
			<!-- Is its usage appropriate in this context (i.e. ReviewFilingResponse) ? Ans: No. -->
			
			<!-- When used, should Service Recipient ID have the same value as in the filing:FilingMessage ? Ans: Yes. -->
			<!-- Commented out since this element is not appropriate in the ReviewFilingRequest response scenario
			<ecf:ServiceRecipientID>
				<nc:IdentificationID>20</nc:IdentificationID>
			</ecf:ServiceRecipientID>
			-->
			
			<!-- Should ecf:ServiceStatusCode be used in this context ? -->
			<!-- Ans: No, this element is for use, along with ecf:ServiceRecipientID, on the response from the ServeFiling operation. --> 
			<!-- Does this element have a domain of valid values ? Ans: Yes, see ServiceStatusCode.gc -->
			<!-- The valid values from ServiceStatusCode.gc are: delivered, opened, sent, unrecognized -->
			<!--
				delivered		- filing has been received by service recipient
				opened			- filing has been opened by service recipient
				sent			- filing sent by MDE to service recipient
				unrecognized	- filing ID is not recognized
			-->
			<!-- Commented out since this element is not appropriate in the ReviewFilingRequest response scenario
			<ecf:ServiceStatusCode>delivered</ecf:ServiceStatusCode>
			-->
			<!-- Message ID for this Response Message per 6.2.5 -->
			<nc:DocumentIdentification>
				<nc:IdentificationID>T6745R5609</nc:IdentificationID>
				<nc:IdentificationCategoryDescriptionText>messageID</nc:IdentificationCategoryDescriptionText>
				<nc:IdentificationSourceText>CourtRecord</nc:IdentificationSourceText>
			</nc:DocumentIdentification>
			
			<nc:DocumentIdentification>
				<!-- Returning Message Identifier from RecordDocketingMessage -->
				<nc:IdentificationID>90K7678-I07</nc:IdentificationID>
				<nc:IdentificationCategoryDescriptionText>messageID</nc:IdentificationCategoryDescriptionText>
				<nc:IdentificationSourceText>FilingReview</nc:IdentificationSourceText>
			</nc:DocumentIdentification>

			<nc:DocumentIdentification>
				<!-- Returning the [ECF] Filing Identifier assigned by FRMDE --> 
				<nc:IdentificationID>897065001</nc:IdentificationID>
				<nc:IdentificationCategoryDescriptionText>filingID</nc:IdentificationCategoryDescriptionText>
				<nc:IdentificationSourceText>FilingReview</nc:IdentificationSourceText>
			</nc:DocumentIdentification>
						
		</ecf:MessageStatusAugmentation>
	</cbrn:MessageStatus>
	
</wrapper:ReviewFilingResponse>
