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 … 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).

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 The physical location of an individual or organization. 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 Implementation Steps: 1. Create a “Schematron Rules File” (very human readable) OWWQX Rule 27: Either ActivityDepthAltitudeMeasureValue or ActivityTopDepthAltitudeMeasureValue must be reported when activity type is. (Activity ID: ) OWWQX Rule 28: Either ActivityDepthAltitudeMeasureValue or ActivityBottomDepthAltitudeMeasureValue must be reported when activity type is. (Activity ID: ) 123 4

19 Schematron Implementation Experience Implementation Steps: 2. Apply a schematron stylesheet to the “Rules File” Schematron Rules File (from Step 1) Schematron Preprocessor ( schematron -basic.xsl) 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 newly created Stylesheet Your XML instance file 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: 1.Learning curve is high –Very little documentation available, esp. examples 2.Remember what schematron can do and what it can’t do 3.Documentation of rules (putting xpath values in error messages) 4.If implementing at CDX, additional options are available