Exchange Network Shared Schema Components

1. Exchange Network Shared Schema Components

2. Shared Schema Components Topics: • Introduction to Shared Schema Components • Purpose/value of using Shared Schema components (include note about EN xml conformance) • Existing SSC 1.0 implementation examples (TRI, CAFO, HLS, NJ-Taxation) • Review SSC 2.0 file contents • SSC Integration • Integration options • Integration example • Identify SSC 2.0 documentation (Usage Guide, Technical Reference, SSCs)

3. Intro to Shared Schema Components What are Shared Schema Components (SSC)? • Reusable XML Schema that organize related data elements • Incorporate EDSC data standards for… • Data element naming • Data element definitions • Data element grouping • (can be thought of as XML representations of EDSC data standards)

4. Intro to Shared Schema Components Why use them? • Flow/schema development • Reusability • Data Quality • Stability • Promotion of common tools

5. Intro to Shared Schema Components Development History

6. Intro to Shared Schema Components Shared Schema Components have already been implemented in several schemas: • CAFO • (Uses 6 SSCs) • TRI 1.0 Schema • (Uses 19 SSCs) • NJ Taxation Schema • State-specific schema • Homeland Security Schemas • Storage Tank • Environmental Incident • OWWQX 1.0

7. Intro to Shared Schema Components Contents: • Shared Schema Components consist of: • 1 “Master Content” file • 58 Shared Schema Components that arrange elements from the Master file into reusable business objects (e.g. FacilitySiteIdentity)

8. Intro to Shared Schema Components Contents: • 1 Simple Content “Master” File • Defines types (either Simple or Complex) for each of the 290+ items referenced in the SSCs • Type definitions kept very open for flexibility • Very few Enumerations • Very few Facet length restrictions • Global element created for each type • To allow reference by SSCs and others • <xsd:simpleTypename="FacilitySiteNameDataType"> • <xsd:restriction base="xsd:string"/> • </xsd:simpleType> • … • <xsd:element name="FacilitySiteName" type="FacilitySiteNameDataType"> • <xsd:annotation> • <xsd:documentation>The public or commercial name of a facility site (i.e., the full name that commonly appears on invoices, signs, or other business documents, or as assigned by the state when the name is ambiguous).</xsd:documentation> • </xsd:annotation> • </xsd:element>

9. Shared Schema Components Contents: • 58 Shared Schema Components

10. Shared Schema Components SSC Integration Options • High Integration: Instances where SSC elements or data types with complex content are directly integrated into the target schema without modification. • Medium Integration: Instances where SSC elements or data types with complex content are modified through the process of XML extension and/or restriction before being included into the target schema. • Low Integration: Instances where elements or data types with simple content are integrated into the target schema.

11. Shared Schema Components “High Integration” Example

12. Shared Schema Components “High Integration” Example <?xml version="1.0" encoding="utf-8" ?> -<xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" version="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:includeschemaLocation="SC_SimpleContent_v2.0.xsd" /> <xsd:includeschemaLocation="SC_StateIdentity_v2.0.xsd" /> <xsd:includeschemaLocation="SC_CountryIdentity_v2.0.xsd" /> <xsd:includeschemaLocation="SC_CountyIdentity_v2.0.xsd" /> <xsd:includeschemaLocation="SC_TribalIdentity_v2.0.xsd" /> -<xsd:complexType name="LocationAddressDataType"> -<xsd:sequence> <xsd:elementref="LocationAddressText" minOccurs="0" /> <xsd:elementref="SupplementalLocationText" minOccurs="0" /> <xsd:elementref="LocalityName" minOccurs="0" /> <xsd:elementref="StateIdentity" minOccurs="0" /> <xsd:elementref="AddressPostalCode" minOccurs="0" /> <xsd:elementref="CountryIdentity" minOccurs="0" /> <xsd:elementref="CountyIdentity" minOccurs="0" /> <xsd:elementref="TribalLandName" minOccurs="0" /> <xsd:elementref="TribalLandIndicator" minOccurs="0" /> <xsd:elementref="LocationDescriptionText" minOccurs="0" /> </xsd:sequence> </xsd:complexType> -<xsd:element name="LocationAddress" type="LocationAddressDataType"> -<xsd:annotation> <xsd:documentation>The physical location of an individual or organization.</xsd:documentation> </xsd:annotation> </xsd:element> </xsd:schema> Location Address Shared Schema Component

13. Shared Schema Components “High Integration” Example

14. Shared Schema Components SSC Related Documentation • SSCs: 59 schema files • SSC Usage Guide: Describes (in further detail) how to integrate SSCs into your schema, SSC customization techniques • SSC Technical Reference: Basically an MS Word representation of the SSCs. • Core Reference Model: High-level depiction of major groupings of environmental data; describes potential areas for future SSC development

15. Schematron Implementation Experience

16. Schematron Implementation Experience What is it? • A way of using XPath and Expressions to validate that an XML file obeys certain rules How was schematron used?: • EPA Office of Water: Water Quality Exchange (OWWQX) • Used to enforce conditional rules, rules across different nodes of XML instance files • if element A=“B”, then element C is mandatory • If element A=“B”, then either element C or D must equal “E” • Also used to enforce database lookup validation (caveat)

17. Schematron Implementation Experience What you need to get started: • Schematron “preprocessor” (I used schematron-basic.xsl, which you can grab off the web) • Schematron “rules file” (you create this) • Program that can apply stylesheet to xml files (XML Spy, etc…)

18. Schematron Implementation Experience 1 2 3 4 Implementation Steps: • 1. Create a “Schematron Rules File” (very human readable) <schema …> <pattern name=“Conditional Checks”> <rule context="owwqx:ActivityDescription"> <report test="contains(owwqx:ActivityTypeCode,'Sample') and normalize-space(owwqx:ActivityDepthAltitudeMeasureValue)='' and normalize-space(owwqx:ActivityTopDepthAltitudeMeasureValue)=''">OWWQX Rule 27: Either ActivityDepthAltitudeMeasureValue or ActivityTopDepthAltitudeMeasureValue must be reported when activity type is <value-of select="owwqx:ActivityTypeCode"/>. (Activity ID:<value-of select="owwqx:ActivityIdentifier"/>) </report> <report test="contains(owwqx:ActivityTypeCode,'Sample') and normalize-space(owwqx:ActivityDepthAltitudeMeasureValue)='' and normalize-space(owwqx:ActivityBottomDepthAltitudeMeasureValue)=''">OWWQX Rule 28: Either ActivityDepthAltitudeMeasureValue or ActivityBottomDepthAltitudeMeasureValue must be reported when activity type is <value-of select="owwqx:ActivityTypeCode"/>. (Activity ID:<value-of select="owwqx:ActivityIdentifier"/>) </report> </rule> </pattern> </schema>

19. Schematron Implementation Experience Implementation Steps: • 2. Apply a schematron stylesheet to the “Rules File” Schematron Preprocessor (schematron-basic.xsl) Schematron Rules File (from Step 1) Your newly created stylesheet

20. Schematron Implementation Experience Implementation Steps: • 3. Apply the schematron stylesheet to the XML instance file to generate an error report Your XML instance file Your newly created Stylesheet Error Report Note: Steps 1 & 2 are one-time tasks, step 3 is repeated for each time you want to validate an XML file

21. Schematron Implementation Experience Lessons Learned: • Learning curve is high • Very little documentation available, esp. examples • Remember what schematron can do and what it can’t do • Documentation of rules (putting xpath values in error messages) • If implementing at CDX, additional options are available