1 / 33

USW.XML Working Group DON.XML NDR Assessment

This document presents the assessment of the DON.XML NDR and its relationship with the Core Components Technical Specification (CCTS). It includes a review of value-add, XML schema alternatives, and best practices.

jackiee
Download Presentation

USW.XML Working Group DON.XML NDR Assessment

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. USW XML Working GroupDON XML NDR Assessment Presented by:Gary Sikora, 703.368.6107x109, gary.sikora@progeny.netPrepared by:Susan Borgrink, 703.368.6107x132, susan.borgrink@progeny.netJohn Kugelman, 703.368.6107x169, john.kugelman@progeny.netBarry Landin, 703.368.6107x189, barry.landin@progeny.netGary Sikora, 703.368.6107x109, gary.sikora@progeny.net 12 October 2005, Rev BDocument: P000766

  2. Agenda • Purpose • 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

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

  4. 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

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

  6. 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.

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

  8. 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

  9. 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?

  10. 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

  11. 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

  12. USW XML Working GroupDON XML NDR Assessment Process - CCTS to XML Schema Terms - Value-Add Definition - Remove Reasons Definitions - Best Practice Definition

  13. Representation terms, CCTs Object class, aggregate BIE Person Properties, basic BIEs Properties, association BIEs Name: textBirth: date Residence address: AddressOfficial address: Address Process – CCTS to XML Schema Terms Representation terms, aggregate BIEs

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

  15. 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.

  16. 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.

  17. 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.

  18. 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.

  19. 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.

  20. USW XML Working GroupDON XML NDR Assessment Results - Summary - Removed Rules - Best Practices - Value-Add

  21. 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

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

  23. Results – Removed Rules • 66 rules were removed of 107.

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

  25. 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.

  26. USW XML Working GroupDON XML NDR Assessment Recommendations - Members Review - Submit to DON XML

  27. 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

  28. 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

  29. 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

  30. 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>

  31. 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"> • <xsd:annotation> • <xsd:documentation xmlns=""> • <cdp:ASBIEComponent xmlns=""> • <cdp:UID xmlns="">AS0001</cdp:UID> • <cdp:CategoryCode xmlns="">ASBIE</cdp:CategoryCode> • <cdp:DictionaryEntryName xmlns="">AbsolutePosition.Latitude.LatitudeAngleMeasure</cdp:DictionaryEntryName> • <cdp:Version xmlns="">1.0</cdp:Version> • <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"> • <xsd:annotation> • <xsd:documentation xmlns=""> • <cdp:ASBIEComponent xmlns=""> • <cdp:UID xmlns="">AS0003</cdp:UID> • <cdp:CategoryCode xmlns="">ASBIE</cdp:CategoryCode> • <cdp:DictionaryEntryName xmlns="">AbsolutePosition.Altitude.Measure</cdp:DictionaryEntryName> • <cdp:Version xmlns="">1.0</cdp:Version> • <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>

  32. 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

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

More Related