‘Production’ Exchange Levels (PEL)

1. ‘Production’ Exchange Levels (PEL)

2. Reference Environment Outbound Reference Inbound Reference DB DB XML Payload Msg SQL Query Map Message Message Flat File Incl. XML Flat File Incl. XML HTML Map Go/ No Go Go/ No Go Validate Validate Metadata Management

3. Above Level 0… XML Payload Flat File Incl. XML HTML Go/ No Go Go/ No Go Validate Validate Metadata Management

4. Business Rules DB XML Payload Map Flat File Incl. XML Flat File Incl. XML HTML • Mapping Today: • XSL – stylesheets (can not read/write to DB). Little or no automated support from metadata management • Middleware– Limited XML Schema supported, if any. Some can use sample input instance as starting point Map Metadata Management

5. Metadata Management Support • Mapping Today: • XSL extensions are possible, but tool vendors are building to existing middleware products or building transformation products where user has more control and features can be added • Little or no automated support for complex business rules • Mapping Future: • Products should provide better support for XML Schema as a starting point • Proprietary products shown promise in the way of opening up business rule definitions (in XML) • Linking to Registry for definitions, lookups and active mapping services Today Stylesheet XSL XML Schema Registry Lookups Business Layers Ontology Metadata Management

6. Metadata Management Support Registry Today: Registry Future: • Concept – Logical – Physical • Element Relationships • Rich Classifications • Context lookups • Data Dictionary • File Listings with attributes • Web/Internet hyper-linking File Resolution Element Resolution Today Stylesheet XSL XML Schema Registry Lookups Business Layers Ontology XSL XSD XML Referencing Much like domain tables in databases Context-based Extensions Libraries XSD XSD WSDL Web Services Support (EISL, UDDI, etc.) Types for user defined data; limited assembly definitions

7. Living in Today’s Toolset Adding Trading Partner Constraints • Single Schema Simple management, superset errors are to be caught at level 3 inbound processing No additional constraints XSD XSD • Additional Constraints Subsetting by: • Derivation (extending) • Copy & Paste XSD Derived or copied • Additional Constraints • Subsetting by ‘Substitution Groups’ only those business artifacts which constraints (codelists, etc.) are applied, main structure stays constant XSD XSD linked

8. Linking to the Next Steps Metadata Management: Adding Trading Partner Constraints • Users need to ‘buy’ into Element Resolution, requires understanding of Return on Investment (ROI) - reuse, context sensitivity, & reduction duplication • Critical for EISL vision and providing standard mechanisms vs standard data • Element Resolution tools need to be developed (internally or COTS) File Resolution Element Resolution Today Stylesheet XSL XML Schema Registry Lookups Business Layers Ontology Classifications and associations added to registry, generic abstract ‘classes’ get created for navigation and understanding 4 3 XML XSD Lookup calls to Registry return XML in the form able to be used by middleware } X 2 Context-based Extensions Libraries 1 XSD XSD Files are broken into Registry entries Physical schemas are generated from Conceptual artifacts (XML Schemas, XML)

9. Other Issues

10. Named Datatypes Also reference previous email exchange & Tom Gavin article • Bruce’s positions • One level deep only; to be used when enumerated lists (code lists) need to be reused • No derivations by extending or restriction, primarily an element world. • Nauman’s positions • When in doubt, make it a datatype (golden rule) • If the item’s content is to be reused, use named datatypes • If the element’s tag name need not be enforced, use named datatypes • When enumerated lists (code lists) need to be reused, use named datatypes • If the hiding of namespaces (for readability perhaps) in instance documents is important, use named datatypes (named datatypes do not require that their namespace “carry through” to their binding elements) • Derivations (by extenstion or restrictions) limited to no more than 3

11. Substitution Groups • Bruce’s positions • Aliasing • Conceptual: Okay for definitions • Phyisical: not to be used (should strive for adding constraints, deciding ahead of time, otherwise processing of transaction becomes very complex) • Reference class schema w/ user objects (eg, XBRL’s usage of ‘assets’ for ‘item’) • Nauman’s positions • can be used for aliases • an element can participate in one and only one substitution group • OAGIS is a big supporter of substitution groups, so we may want to investigate further • limited capability, since they can only be used when substituting global elements • inside <all> model groups, substitution groups can cause problems (since maxOccurs=1 automatically inside <all> groups, and if both the element and its substitute needs to be used, eg, DepartmentCode and TradingPartnerCode in the ATB)

12. Oracle subtypesand XSD equivalents

13. Oracle subtypes Document - DocID - Date PO - A Contract - B

14. A.xsd (uses Elements only, no Named Datatypes) Document PO Contract

15. A.xsd - graphical view

16. B.xsd (uses named datatypes and elements) Note to Nauman: As shown, PO and Contract can not standalone, they haven’t been defined as global reusable components; is this an oversight?

17. B.xsd - graphical view

18. In this simple example, the difference between the 2 approaches is basically a wash In the text view, A.xsd has a ‘cleaner’ and simpler look In the graphical view (XML Spy dependency), it is easier to see where reuse is taking place in B.xsd A.xsd is in fact slight longer than B.xsd C.xml (validated by both A.xsd and B.xsd)

19. Introducing Named Groups D.xsd (uses named groups and elements)

20. D.xsd - graphical view Named groups

21. The content model is different from both A.xsd and B.xsd; but that maybe the business requirement! Notice that ‘Document’ becomes a group and therefore, does not show up in the instance doc; only its content does (DocID and Date) E.xml (validated by D.xsd)

22. Metadata Generation and Deployment { • Business Users decide on Production Exchange Level (PEL) for their information integration • Today’s databases are the starting point for schemas (XSD) and programming classes • Modeling (UML, Oracle Designer, etc.) provide schema (XSD) for data aspects • Web services can be used to support functions such as validation (levels 1 & 2) • Programs/tools can be developed or procured for easing documenting, designing and implementing. • Guidelines, procedures and package descriptions need to be developed to assist developers/users • Education of users • Registry prototype needs to be upgraded and tested or alternative (webpage/DirFile) needs to be in place and online

23. Metadata Generation and Deployment Con‘t • Typically the W3C isn’t focused on eBusiness, as per its charter to provide for core technologies. DFAS needs to specify areas where (1) additional constraints need to be imposed to support eBusiness, (2) areas which need to be extended to support eBusiness, (3) addressing the needs of DFAS database-centric environment, (4) where exchanges are dynamic, sometimes ad hoc, where the use of generated business artifacts from the current knowledge/tool base, (5) taking into account DFAS modeling and development policy, eg. ER/UML generated schemas, thus (6) addressing issues required to support DFAS’ enterprise metadata management vision. • All approaches have their pros/cons and therefore, decisions on which to choose need to made on a case-by-case basis. DFAS guidance should outline each alternatives’ specifics, and suggest a preferred approach if business drivers do not dictate one method over another.