Welcome to the online validator for NEMSIS V3 XML file.
This application validates the EMS data submitted using NEMSIS V3 Web Service interface.
When the server receives a NEMSIS V3 XML file, XML validation and business rule checking (Schematron) will be executed.
- Targeted audience:
developers with knowledge of SOAP Web Service.
Note: When NEMSIS TAC releases new XSD and/or Schematron rule, this site will be updated accordingly.
- The NEMSIS V3 release requires that all data submissions to NEMSIS TAC use published Web Services interface.
- It is required to use HTTPS as the communication method.
- This application only covers the first few steps in the overall workflow of a NEMSIS V3 submission: Web Service submission, XML validation and business rule (Schematron) validation.
It DOES NOT indicate any tool preference by the NEMSIS TAC.
- NEMSIS V3 WS interface defines three common interfaces (functions, or operations).
Only SubmitData is implemented. You can send SOAP message to test the other functions. Only dummy responses are provided.
- To submit test data, do the following:
- Contact the NEMSIS TAC (Email: email@example.com) to
open an account if you do not have a NEMSIS TAC account yet.
- Develop your Web Service client. Or, install soapUI if you just want to get a feeling.
Get familiar with soapUI.
- In the Web Service client, reference this site's WSDL.
(If using soapUI, create a soapUI project by referencing this site's WSDL.
Then create test cases for SubmitData, RetrieveStatus and QueryLimit.)
- Generate the request SOAP message, fill in all required parameters and submit the WS request. You can use the sample SOAP messages as starting point. Make sure username and password are correct!
- Request Parameters for SubmitData(). (RetrieveStatus() will get an error message.)
To have fun, you can play with different combination of parameters to check out the error messages.
- "username" and "password": clear text. Remember, the SOAP message is sent by HTTPS.
- "organization": could be anything. It does not matter.
- "requestType": only value of "SubmitData" is truly processed.
- "submitPayload": use payloadOfXmlElement to embed the NEMSIS XML file.
- "requestDataSchema": either "61" for NEMSIS EMS data or "62" for NEMSIS Demographics data.
- "schemaVersion": only "3.3.4" or "3.4.0" is accepted.
- Some versions of soapUI introduce non-UTF-8 character(s) when creating the skeleton SOAP message of
a test case. Make sure that in requestData element, "<?xml" directly follows "<![CDATA[" if you
use PayloadOfString to embed XML file.
So the start of requestData should be something like "<![CDATA[<?xml" if you encounter
error message like "Invalid byte 1 of 1-byte UTF-8 sequence...".
- Response SOAP Messages
It is required for the NEMSIS WS client to properly decode the response SOAP messages to find out the
server's action for the submitted data.
Since this is a site only for validation, we are not going to import any submission into database.
Also, the "requestHandle" element in the response is populated with some string value instead of system unique ID. It cannot be used to retrieve processign status.
Depends on the request SOAP message, you might get one of these response status code:
- 1: XML validation passed. And no Schematron FATAL error is found. Thumbs up!!!!!
- -1: Invalid username and/or password
- -4: requestType not equals to "SubmitData"/"", or schemaVersion not equals to either 61 or 62
- -5: schemaVersion not equals to "3.3.4" or "3.4.0"
- -12: XML validation failed
- -13: XML validation passed. But at least one Schematron FATAL error is found.
- -101: NEMSIS XML payload is not included in the SOAP message, or something wrong when we try to save the payload to file system.
- -20/-21/-22: something wrong with our server
- If PayloadOfXmlElement is used to embed XML file, Java JAX_WS RI automatically loads and
parses the embedded string to DOM tree. This means if your XML file is not well-formatted,
JAX-WS will throw exceptions even before Web Service implementation codes are reached.
The response message will be a SOAP fault message. If the XML file is well-formatted,
this validator will write the DOM to an indented (pretty-print) XML file. A side effect is that the
line/column number in this generated XML file will not be same as the original embedded file.