1. USW XML Working Group DON XML NDR Assessment Presented by: Gary Sikora, x109, Prepared by: Susan Borgrink, x132, John Kugelman, x169, Barry Landin, x189, Gary Sikora, x109, 12 October 2005, Rev B Document: P000766

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

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

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

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

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 Group DON XML NDR Assessment Results. - Summary
USW XML Working Group DON 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 Group DON XML NDR Assessment Recommendations
USW XML Working Group DON 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">
<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>

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 …