This section provides instructions on using the Consolidated Emissions Reporting Schema (CERS) to submit data to the EIS.
This section provides a basic overview of XML and the CERS and includes references to complex types that should not be reported to the EIS. The CERS is used to report data to many other data flows and therefore includes additional reporting capabilities.
The following terminology are some of the key terms related to XML and data submission to the EIS.
Namespace | A namespace uniquely identifies a set of names such that there is no ambiguity when objects having different origin but the same names are mixed together. |
Markup Language | A way to combine text and extra information to show the structure and layout of a document. This information is expressed using markup, which is typically intermingled with the primary text. A commonly known markup language is HTML. |
Tuple | An ordered list of objects, each of a specific type. The CERS uses valued pairs consisting of a parameter name and a parameter value to report optional data elements to the EIS. |
XML | A markup language for documents containing structured information. The XML specification defines a standard way to add markup to documents. Its primary purpose is to facilitate the sharing of structured data across different information systems, particularly via the internet. |
XML Schema | An XML schema describes the structure of an XML document. An XML schema defines the set of rules to which the XML document must conform in order to be considered "valid" according to its schema. An instance of an XML schema is an XML schema document and is a file with the extension .xsd. |
XML Document | An XML document is a file containing data organized into a structured document using XML markup. An XML document is considered to be "well-formed" if it conforms to all XML syntax rules. An XML document is considered to be "valid" if it conforms to all the semantic rules defined by an associated XML schema. An XML document cannot be processed if it is not well-formed or valid. XML documents have the file extension .xml. |
XML Element | An XML element is a unit of the XML document that is expressed as tags in the form "<tagname>". XML elements must have either a start and end tag as in <FacilitySite> </FacilitySite> or a single empty tag name as in </FacilitySite>. XML elements may be nested within one another in a structured hierarchy and sequence specified in an XML schema. |
XML Attribute | An XML attribute contains additional information about an XML element placed at the start tag of the XML element. XML attributes have the form attributeName = "attributeValue," as in <StateCode="CA">. EIS will use XML attributes to report identifying information or to help the EIS process the data being reported within the EIS elements |
XML Simple Type | An XML element which has no attributes or nested elements. |
XML Complex Type | An XML element which has attributes or nested elements. All EIS components described in other section of this document are XML complex types comprised of XML simple types and other complex types. |
CDX | The Central Data Exchange (CDX) serves as the EPA node on the Exchange Network and is the gateway for receiving environmental information through the Web. |
Component | A component is a group of XML elements. This term is used in other sections of this document to be synonymous with "complex type." |
Content Type | Denotes the particular form of content. For the purposes of this document, the content types referenced in the EIS schema are elements, attributes, complex types, and attachments. |
Data Block | A logical grouping of data elements and other data blocks defined for the purposes of reporting data. |
Data Category |
The category of emissions inventory data to be reported. For
the EIS, these
are:
|
Data Element | The smallest discrete unit of information that can be reported and still have meaning between systems. Examples of data elements are Agency identifiers, State codes and stack height measure. The EIS will process data elements as part of XML complex types corresponding to complex types defined as part of the reporting instructions. |
Data Type | The data format defined for a given data element. Common data types include string, integer, and date. EIS requires that all data elements reported in the XML document have a data type of string. These data will be converted by the EIS to the data types defined for each data element in the reporting instructions. For example, the data element EndDate must be reported in XML as a string, but will be converted by the EIS to a date as defined in the various sections of the reporting instructions. |
Exchange Network | A secure Internet - and standards-based approach for exchanging data. |
Major Data Group | A logical grouping of related Data Blocks that fully describe business area, functions, and entities. |
Node | A web server that facilitates the interface between database systems and the Exchange Network. It is a partners "point of presence" on the Exchange Network. |
Node Client | A type of node that can submit, request, and receive data on the Network, but cannot respond to data queries from other Nodes. |
Submittal Data Block | The set of data blocks that can be submitted together for a category of data. These submittal data blocks are defined for each data category and contain the minimal complex types necessary to report data such that the EIS can successfully process and integrate the data into the inventory. |
Web Client | A web-based submission tool that sends data to the CDX Node over the Exchange Network. It cannot receive data on the network or respond to data queries from other nodes. |
An XML schema is the definition that constrains the structure and content of an XML document written in XML Schema language as defined by the World Wide Web Consortium (W3C). An XML schema defines:
Like the architectural blueprint that describes the structural design of a house, an XML schema describes the structural design of an XML file.
Files submitted to the EIS are accepted or rejected based on their conformity to the EIS XML schema.
The domain model views show the associations between entities and therefore may resemble a relational model, similar to how a database may be represented. In comparison, the CERS structure is hierarchical, though it is possible to see a partial representation of the relational aspects of the EIS domain model in the schema complex types. The complex types themselves loosely correspond to tables; each complex type has elements that describe identity and contains data values.
Within the CERS, the hierarchical structure is a partial representation of the relational aspects of the complex types. This can be seen in the way that each complex type nests within another complex type. The nesting of that complex type in the schema demonstrates that the data in that complex type is likely to be stored in a table joined to another table in a relational database.
XML elements are individual pieces of data that correspond to columns in a table in a database. Complex types have only XML elements. These complex types contain data that is related to the owning entity by virtue of the nesting hierarchy in the XML schema.
Any submission files sent to the EIS must use the Header Document structure to meet EPA CDX processing requirements for transporting the file through the Exchange Network. The Header Document serves as a wrapper around the four different types of payloads that the EIS accepts (Facility Inventory, Point, Nonpoint/OnRoad/NonRoad, and Events) and contains the following information, or metadata, about the submission:
The header is required to be provided for all Submit operations through the Exchange Network
The header is required to be provided for all Submit operations through the Exchange Network
The root element of the header document is the Document element, with two child elements, Header and Payload. The Payload contains the actual EIS data, adhering to the structure of the CERS. Any supporting documents (for the NMIM activity data or GIS files) are attached in the form of .zip attachments. These data attachments are referenced by name in the CERS payload section of the document, but the data attachment content exists as separate documents external to the XML document. Figure 5-6 shows the file submission structure.
The Document elements are used by the Exchange Network to identifier the document and the default namespace for the header. The CERS payload has a separate namespace for its payload.
Name | Description | Example | Required |
---|---|---|---|
ID | A unique identifier for the payload that is created during the time of submission. | ID123456789 | Yes |
XML Namespace | The Exchange Header 2.0 namespace. This is not the CERS namespace which is contained in the CERS document. | http://www.exchangenetwork.net/schema/header/2 | Yes |
The header document contains information on the individual that generated and submitted the XML file (this may not be the same person who prepared the data), the organization that prepared the data, the date and time the file was created, and any additional comments.
Name | Description | Example | Required | Notes |
---|---|---|---|---|
AuthorName | Originator of the document. This should be the name of a person or a network node ID if the document is automatically generated. | John Smith | Yes | Used for reference only. |
OrganizationName | The organization to which the author belongs. It may be a state name, an organization name or a company name. For submissions to the CDX node, this should be the name of the organization. | State X Department of Environmental Quality | Yes | Used for reference only. |
DocumentTitle | Title of the document. | Must be "EIS" | Yes | Reference to the flow. |
CreationDateTime | This is a timestamp that marks when the document, including payloads and header part, was created. | 2006-04-05T09:30:47-05:00 | Yes | Must be in valid xsd:datetime format. |
Keywords | Words that best describe the payload. Multiple keywords should be separated by commas. This is for transaction categorization and searching. | No | ||
Comment | Additional comments for processors. | The payload contains Point Data. | No | |
DataFlowName | The name of the data flow associated with the payload. It could be the name of the data source for Query results. | CERS_v2 | Yes | |
DataServiceName | Not used by EIS. | No | ||
SenderContact | The sender's additional contact information. It could contain sender's electronic address and/or telephone numbers where the author can be reached. | P.O. Box 1234Richmond, VA | No | Element is not used by EIS. If data is provided it will be ignored. |
ApplicationUserIdentifier | The user identifier for the backend system if it is different from the NAAS user ID. | No | Element is not used in the EIS exchange. If a value is provided, it will be ignored by the EIS node and destination processor. | |
SenderAddress | A well-formed URI where results or reports can be sent. | No | Element is not used by the EIS. | |
Property | Other properties of the document using named value pairs. Property Name and Property Value | Yes | ||
Signature | An XML signature associated with the document. | No | Element is not used by the EIS. |
Name | Description | Example | Required | Notes |
---|---|---|---|---|
ID | A unique identifier for the payload. | No | Element is not used by EIS. | |
Operation | Identification of the payload content which triggers an operation. | No | Element is not used by EIS. |
Name | Description | Example | Required |
---|---|---|---|
SubmissionType | Production QA | <hdr:PropertyName>SubmissionType</hdr:PropertyName><hdr:PropertyValue>Production</hdr:PropertyValue> | Yes |
DataCategory | FacilityInventory Point Nonpoint Onroad Nonroad Event | <hdr:PropertyName>DataCategory</hdr:PropertyName><hdr:PropertyValue>FacilityInventory</hdr:PropertyValue> | Yes |
NCDDataFile | Name of NCD file | <hdr:PropertyName>NCDDataFile</hdr:PropertyName><hdr:PropertyValue>NCDActivityData12000.zip</hdr:PropertyValue> | No |
The following example demonstrates how the exchange header document is used as a wrapper to the CERS data.