USW XML Working Group DON XML NDR Assessment Presented by: Gary Sikora, 703.368.6107x109, gary.sikora@progeny.net Prepared by: Susan Borgrink, 703.368.6107x132, susan.borgrink@progeny.net John Kugelman, 703.368.6107x169, john.kugelman@progeny.net Barry Landin, 703.368.6107x189, barry.landin@progeny.net Gary Sikora, 703.368.6107x109, gary.sikora@progeny.net 12 October 2005, Rev B Document: P000766

Agenda Purpose Process Results Recommendations Background Assess CCTS Need Determine Value-Add XML Schema Alternative Process CCTS -> XML Schema Terms Value-Add Definitions Removal Reasons Definitions Best Practice Definition Results Summary Removed Rules Best Practices Value-Add Recommendations Members Review TAML Example Submit to DON XML

USW XML Working Group DON XML NDR Assessment Purpose. - Background USW XML Working Group DON XML NDR Assessment Purpose - Background - Assess CCTS Need - Determine Value-Add - XML Schema Alternative

Purpose – Background Core Components Technical Specification (CCTS) Developed by United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) Part of ebXML Framework Bridge XML based information exchange and Electronic Data Interchange (EDI) systems Not just XML Schema – ANSI ASC X12 or UN/EDIFACT Universal Business Language (UBL) adopted CCTS and ISO 11179 DON XML NDR based on the UBL NDR (Naming and Design Rules) which uses CCTS

Purpose – Background (cont.) ebXML Framework CCTS Defined CCTS Used

Purpose – Background (cont.) ebXML CCTS Requirements Be developed in conjunction with the Business Process Project Team Identify a methodology for describing core components within the framework of the Business Process metamodel Define core component content and structure Support “re-use” and extensibility Provide methodology and examples for XML and EDI instantiation Enable creation of XML business standards Be syntax independent Be defined to ensure separation of common core components versus new extensions Incorporate where appropriate ISO/IEC 11179 rules14, 15,16,17,18,19 Use semantics solutions that accommodate currently defined accredited EDI semantics where they add value Use a single consistent set of terminology Support context sensitive core components ebXML CCTS Team Objectives Define a process, by which information components can be discovered, catalogued in sufficient detail and analysed to identify which components are core components. The creation of such a catalogue will enable interoperability across industries that utilize electronic commerce.

Purpose – Background (cont.) ebXML CCTS Use Document assembly Core Components are extracted from the repository and used to create a schema model That can then be used to create an XML schema For example, a Purchase order schema may consist of two parties (buyer, seller), and a sequence of items Purchase orders are not Core Components; they must be assembled out of Core Components found in the repository Discovery and Analysis Discovery and analysis of Core Components and common Business Processes used in the interchange of business information. Including the impact of context, that are used in information exchange It also explains that the results of these activities should be compared against entries found in public repositories and that these comparisons will result in either the creation of new or the updating of existing entries within the repository.

Purpose – Background (cont.) CCTS Summary CCTS is an ontology framework designed to exchange of electronic business data CCTS ontology is used throughout model definition, discovery, analysis and mapping parts of the framework CCTS assumes artifacts are already represented at the information level For example, business names, addresses, products, costs, etc. CCTS ontology does not have concepts to support data modeling Unit definition Algorithm definition Fan-in and fan-out mappings CCTS Ontology Framework Built for Electronic Business Data

Purpose – Assess CCTS Need USW-XML Assumptions XML to be modeled is system integration data, not business data Measurement type – data has units, uncertainty, resolution and pedigree No need to model data in secondary representation to support multiple instantiations The approach underway by system integrators and standards bodies such as OMG is to map from XML Schema to other modeling languages such as IDL and database schemas Is CCTS required to express DON XML Naming and Design Rules (NDR)? Is CCTS required for understanding? Is CCTS required for reuse or interoperability? Is CCTS required for integration/conformance with UN/CEFACT?

Purpose – Determine Value-Add Convert NDRs to XML Schema and then determine value- add Value-Add includes things such as: Reuse Interoperability Binding Understandability Security Idea – If there is value-add it is a good rule, else why have it

Purpose – XML Schema Alternative The alternative is to express the NDRs in XML Schema constructs and concepts Advantages Developers do not have to learn a secondary language Zero risk of translation error going from CCTS to XML Schema Less risk of misunderstanding the NDRs Disadvantages No longer common with ebXML or UBL No longer common with major industries or other governments Potential pushback from DON XML This is what we set out to determine

USW XML Working Group DON XML NDR Assessment Process USW XML Working Group DON XML NDR Assessment Process - CCTS to XML Schema Terms - Value-Add Definition - Remove Reasons Definitions - Best Practice Definition

Process – CCTS to XML Schema Terms Person Name: text Birth: date Residence address: Address Official address: Address Object class, aggregate BIE Properties, basic BIEs Properties, association BIEs Representation terms, CCTs Representation terms, aggregate BIEs

Process – Value-Add Definitions Interoperability Aids schemas in easily cooperating with each other. User-defined codes are to be stored as enumerations within a separate document. XSD Reuse Aids another schema to reuse that piece using schema constructs. Elements and attributes MUST be based on approved datatypes. Language Binding Aids communication between another language (e.g. Java) and the schema. Mixed content MUST only be used when the element is defined by an approved namespace (e.g. XHTML)

Process – Value-Add Definitions Security Provides users with a security for documents being submitted. W3C XMLDSIG MUST be used to digitally sign XML Components where appropriate. Understandability Aids developers reading another developer’s schema. Abbreviations and acronyms used in element, attribute and type names MUST be submitted and approved.

Process – Removal Reasons Definitions W3C Rule Once reworded into schema terms, a XML Schema rule already stated the rule. Enumerations MAY be restricted locally. Not a NDR Rules that do not govern creating schemas. Schema developers MAY provide a run-time schema devoid of documentation in addition to the fully annotated version. Covered by Another Rule Once reworded into schema terms, another rule within the NDR stated the rule. Abbreviations and acronyms MUST be approved.

Process – Removal Reasons Definitions CCTS Rule Once reworded into schema terms, rule only applied to a CCTS construct or did not make sense with out the CCTS terminology. A complexType containing simpleContent MUST use simpleContent. Authoritative Body Rule Rule applied to an authoritative body approving or mandating namespaces. All approved schema MUST reside in the DON enterprise root namespace. Enforceable by Schema Construct Rule could be enforced by using already provided schema constructs. An objectIDRef attribute MUST be declared globally.

Process – Removal Reasons Definitions Complex Naming Convention Created names which could be confusing and verbose. The name of the parent followed by the name of the element followed by a semantically meaningful term. Other Rules which did not fall into any other category. Reasons were described under the Reason column. All global elements and named complex types MUST reside in the enterprise BIE Reusable Schema module. Replaced Rules which were slightly re-written to be kept. The xsd:unique name MUST have the postfix “Key” instead of “Type” Clarify Rules for which either a meaning could not be deciphered or the phrase “when appropriate” was applied. If a datatype is extended or restricted, it MUST retain its original context.

Process – Best Practice Definitions Rules were split into rules and best practices Naming and Design Rules that used the SHOULD or SHOULD NOT construct were considered guidelines rather than rules. All schema SHOULD use the list of attributes defined by the DON. It is strongly discouraged to define your own attributes.

USW XML Working Group DON XML NDR Assessment Results. - Summary USW XML Working Group DON XML NDR Assessment Results - Summary - Removed Rules - Best Practices - Value-Add

Results – Summary Spreadsheet created when going through the NDR. Prior to comments - DON XML NDR Assessment.xls After comments - DON XML NDR Assessment Comments Review.xls

Results – Summary Summary of all the rules reviewed Excluding the Documentation and Versioning rules. 07 total reviewed

Results – Removed Rules 66 rules were removed of 107.

Results – Value-Add Represents the “yes” votes for each value-add. Each rule may have a “yes” for more than one value-add.

Results – Best Practices Best Practices were included in the removed rules. First chart represents the percentage of “Best Practices” within the “Removed”. Second chart is a comparison of “Best Practices” to rules kept.

USW XML Working Group DON XML NDR Assessment Recommendations USW XML Working Group DON XML NDR Assessment Recommendations - Members Review - Submit to DON XML

Recommendations – Members Review The results are not cast in stone This was a two pass First Susan and Barry Second Susan, Barry, John and Gary We may have missed a value add We may have misunderstood the rule’s intent Many are very difficult to understand The goal is to have USW-XML Working Group concurrence

Recommendations – Initial Review Comments came from Mike Grimley and Don Brutzman 26 recommendations were disapproved 18 recommendations were marked for more discussion 43 recommendations were approved 20 recommendations had no comment

Recommendations – Initial Review (cont.) Reviewed all the disapproved recommendations Reviewed some of the more discussion recommendations 21 were commented on again, left to more discussion 6 agreed with comment – to remove the rule 1 recommendation was changed from keep to remove, due to implementation experience

Recommendations – TAML Example Before NDR <xsd:complexType name="AbsolutePositionType"> <xsd:annotation> <xsd:documentation></xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="Latitude" type="xsd:decimal" minOccurs="1" maxOccurs="1"/> <xsd:element name="Longitude" type="xsd:decimal" minOccurs="1" maxOccurs="1"/> <xsd:element ref="Altitude" minOccurs="1" maxOccurs="1"/> </xsd:sequence> </xsd:complexType>

Recommendations – TAML Example (cont.) After NDR <xsd:complexType name="AbsolutePositionType"> <xsd:annotation> <xsd:documentation xmlns=""> <cdp:ABIEComponent xmlns=""> <cdp:UID xmlns="">A0002</cdp:UID> <cdp:CategoryCode xmlns="">ABIE</cdp:CategoryCode> <cdp:DictionaryEntryName xmlns="">AbsolutePosition</cdp:DictionaryEntryName> <cdp:Version xmlns="">1.0</cdp:Version> <cdp:Definition xmlns="">Complex type Absolute Position Type - Latitude, Longitude and Altitude (optional)</cdp:Definition> <cdp:ObjectClass xmlns="">AbsolutePosition</cdp:ObjectClass> … <xsd:sequence> <xsd:element ref="Latitude"> <cdp:ASBIEComponent xmlns=""> <cdp:UID xmlns="">AS0001</cdp:UID> <cdp:CategoryCode xmlns="">ASBIE</cdp:CategoryCode> <cdp:DictionaryEntryName xmlns="">AbsolutePosition.Latitude.LatitudeAngleMeasure</cdp:DictionaryEntryName> <cdp:Definition xmlns="">Element Latitude is positive degrees North and negative degrees South of the Eauator to fractions of a degree</cdp:Definition> <cdp:Cardinality xmlns="">1..1</cdp:Cardinality> <cdp:ObjectClass xmlns="">Latitude</cdp:ObjectClass> <xsd:element ref="Altitude" minOccurs="0"> <cdp:UID xmlns="">AS0003</cdp:UID> <cdp:DictionaryEntryName xmlns="">AbsolutePosition.Altitude.Measure</cdp:DictionaryEntryName> <cdp:Definition xmlns="">Element Altitude above mean sea level expressed in feet by default.</cdp:Definition> <cdp:Cardinality xmlns="">0..1</cdp:Cardinality> <cdp:ObjectClass xmlns="">Altitude</cdp:ObjectClass> </cdp:ASBIEComponent> </xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType>

Recommendations – TAML Example (cont.) Added CCTS Documentation Added Global Element for every complexType. Unqualified Datatypes (UDT) and adding Qualified Datatypes (QDT) TAML without Documentation – 92 KB TAML with Documentation – 277 KB UDT and QDT schemas – 26 KB

Recommendations – Submit to DON XML Perhaps the answer could be not one ontology framework for all domains This worked for UBL with the defined CCTS – only business data Across the Navy there is: Business – for which CCTS makes sense System – IEEE SUMO ontology seems to be a better fit Training – then there is the SCORM initiative … Perhaps an approach could be to define Navy vertical markets for which interoperability is desired – enterprise systems, tactical systems, learning systems, etc., and look what is being used within the commercial and services space for that particular market. Where do we go from here …