1. 2004-10-0520944 Rationale Overview, F. Farance 1 Rationale Overview For 20944 Series Frank Farance, Farance Inc. frank@farance.com +1 212 486 4700

2. 2004-10-0520944 Rationale Overview, F. Farance 2 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 20944 series: –Prototypical Uses (use cases for interoperability) –Implementation Variants (variety control) –Standards methodologies employed –General interoperability issues API Framework Coding Framework –Separation of Bindings –Separation of Identifiers –Separation of Terminology

3. 2004-10-0520944 Rationale Overview, F. Farance 3 What is a Rationale? Explanations of: –questions: issues raised during development –decisions: import development decisions –design: methods/modules implied –historical data: inputs that influenced process Example: see C rationale –http://www.dkuug.dk/jtc1/sc22/wg14 –click on “Rationale” (third bullet)

4. 2004-10-0520944 Rationale Overview, F. Farance 4 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 20944 series: –Prototypical Uses (use cases for interoperability) –Implementation Variants (variety control) –Standards methodologies employed –General interoperability issues API Framework Coding Framework –Separation of Bindings –Separation of Identifiers –Separation of Terminology

5. 2004-10-0520944 Rationale Overview, F. Farance 5 Why Create A Rationale? Important for standards work: –Participants come and go over the years –Reduces learning curve for new participants –Can refresh memories of “old-timers” :-) –Helps avoid unnecessarily revisiting issues –Helps build user communities by answering questions that aren’t obvious to outsiders –Can help document future issues Outside of standards work: –Also used in software development, typically called “design rationale”

6. 2004-10-0520944 Rationale Overview, F. Farance 6 Who Uses Rationales? Important for large projects Positive example: ISO C prog. language: –Few defect reports / request for interpretation –Large acceptance, broad interoperability Negative example: ISO C++ prog. language –Appox. 700 defects (most are interdependent) –Lack of interoperability, lack of adoption Google with >6000 hits: rationale “iso standard”

7. 2004-10-0520944 Rationale Overview, F. Farance 7 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 20944 series: –Prototypical Uses (use cases for interoperability) –Implementation Variants (variety control) –Standards methodologies employed –General interoperability issues API Framework Coding Framework –Separation of Bindings –Separation of Identifiers –Separation of Terminology

8. 2004-10-0520944 Rationale Overview, F. Farance 8 Rationale for 20944 Series The 20944 series “road map”: 29 parts Overall the approach is a “building blocks” approach, with the following highlights: –Why create a single monolithic standard? Let users pick and choose what they want –Why create extra implementation burden? Structure allows implementers to create only what they need –Describe what to implement, not how Supports wide range of implementations: from simple (low cost) to complex (high performance)

9. 2004-10-0520944 Rationale Overview, F. Farance 9 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 20944 series: –Prototypical Uses (use cases for interoperability) –Implementation Variants (variety control) –Standards methodologies employed –General interoperability issues API Framework Coding Framework –Separation of Bindings –Separation of Identifiers –Separation of Terminology

10. 2004-10-0520944 Rationale Overview, F. Farance 10 Prototypical Uses of 20944 Examples of using 20944: –Extracting value domain, values, and meanings –Extracting data elements and their dependent data element concepts and value domains –Walking classification schemes to discover and inspect administered items –Copying metadata from one registry to another Applications of these examples: –Web interfaces, database application support, support for data stewards / designers, precise communication among stakeholders

11. 2004-10-0520944 Rationale Overview, F. Farance 11 Example Taken From 20944-01 Extracting a value domain from a metadata registry:

12. 2004-10-0520944 Rationale Overview, F. Farance 12 Example Of 20944, Then ISO 11179 Metadata Exchange, Then Data Exchange User Portal Services/AppsWeb Access User Interface, Browser Apps, Services Info/ Knowledge Base Data Server Info/ Knowledge Base Data Server Queries (e.g. via web) Information Exchange Portal, Front End #3: Data Exchange #2: ISO/IEC 11179 Metadata #1: ISO/IEC 20944 MDIB API

13. 2004-10-0520944 Rationale Overview, F. Farance 13 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 20944 series: –Prototypical Uses (use cases for interoperability) –Implementation Variants (variety control) –Standards methodologies employed –General interoperability issues API Framework Coding Framework –Separation of Bindings –Separation of Identifiers –Separation of Terminology

14. 2004-10-0520944 Rationale Overview, F. Farance 14 Implementation Variants (Variety Control) Standard describes what, not how Need to support a variety of implementations –Low performance and high performance Shouldn’t expect all implementations to be high cost Should permit high cost implementations to differentiate themselves: quality of implementation –Spawns innovation –Should be OS/language/coding/protocol neutral

15. 2004-10-0520944 Rationale Overview, F. Farance 15 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 20944 series: –Prototypical Uses (use cases for interoperability) –Implementation Variants (variety control) –Standards methodologies employed –General interoperability issues API Framework Coding Framework –Separation of Bindings –Separation of Identifiers –Separation of Terminology

16. 2004-10-0520944 Rationale Overview, F. Farance 16 Standards and Methodologies Employed JTC1 Directives: –Annex J: Guidelines for API Standardization –Describes much about API standardization, which the 20944 series follows Standards –Uses 13886 (Language-Independent Procedure Calling) and 11404 (General Purpose Datatypes) –Language-independent specifications, as recommended by JTC1 Directives

17. 2004-10-0520944 Rationale Overview, F. Farance 17 Standards and Methodologies Employed Breakdown into Parts –Building blocks correspond the “conformity” boundaries –Why require an implementation to support (say) both C and JavaScript when only one is used? –Separate parts allow clear, unambiguous references to requirements and declarations of conformity (e.g., Part 41 is for C, Part 44 is for JavaScript). –Separate areas for codings, APIs, and protocols — important to keep separate (next slide)

18. 2004-10-0520944 Rationale Overview, F. Farance 18 ISO/IEC 20944 Family of Standards — Dependencies Among the Parts 20944-65 LDAP Protocol Binding 20944-03 Common Conformance Provisions 20944-04 General Usage 20944-02 Common Vocabulary 20944-05 Common Data Structures 20944-06 Semi-Structure Aggregation 20944-21 XML Coding Binding 20944-20 Common Coding Provisions 20944-22 DIVP Coding Binding 20944-23 ASN.1 Coding Binding 20944-47 PHP API Binding 20944-40 Common API Provisions 20944-41 C API Binding 20944-42 C++ API Binding 20944-43 Java API Binding 20944-44 ECMAscript API Binding 20944-45 Perl API Binding 20944-46 LISP API Binding 20944-61 ODBC Protocol Bindings 20944-62 DCTP Protocol Bindings 20944-63 SOAP Protocol Binding 20944-64 WSDL Protocol Binding 20944-66 JMS Protocol Binding 20944-01 Framework 20944-81 11179-3 MDR Attribute Map 20944-82 Profile For 11179-3 MDR 20944-83 URIs For 11179-3 MDR Navigation 20944-80 Common Profiles Provisions 20944-60 Common Protocol Provisions

19. 2004-10-0520944 Rationale Overview, F. Farance 19 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 20944 series: –Prototypical Uses (use cases for interoperability) –Implementation Variants (variety control) –Standards methodologies employed –General interoperability issues API Framework Coding Framework –Separation of Bindings –Separation of Identifiers –Separation of Terminology

20. 2004-10-0520944 Rationale Overview, F. Farance 20 General Interoperability Issues Expect to write code and work on many implementations Expect to share data and have it understood Expect to users will have “extensions” to data

21. 2004-10-0520944 Rationale Overview, F. Farance 21 Building Standards In Several Steps Maintenance Development Review Amendments: 2-3 years Revisions: 4-5 years Consensus Building User/Vendor/ Institutional/ Industry “Extensions” “Extensions” Become Input To Next Revision Of Standard Industry-Relevant, Widely-Adopted “Extensions” The “Standard”

22. 2004-10-0520944 Rationale Overview, F. Farance 22 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 20944 series: –Prototypical Uses (use cases for interoperability) –Implementation Variants (variety control) –Standards methodologies employed –General interoperability issues API Framework Coding Framework –Separation of Bindings –Separation of Identifiers –Separation of Terminology

23. 2004-10-0520944 Rationale Overview, F. Farance 23 API Framework Provide right level of abstraction –as per JTC1 Directives –Not broadening scope, just getting to right level of abstraction to permit wide implementations Key features: –Handle-object paradigm –Two-step connect paradigm –Open security paradigm –Open nomadicity (connectedness) paradigm –Read-write paradigm –Supports multiple datatypes –No requirement (yet) for streaming

24. 2004-10-0520944 Rationale Overview, F. Farance 24 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 20944 series: –Prototypical Uses (use cases for interoperability) –Implementation Variants (variety control) –Standards methodologies employed –General interoperability issues API Framework Coding Framework –Separation of Bindings –Separation of Identifiers –Separation of Terminology

25. 2004-10-0520944 Rationale Overview, F. Farance 25 Coding Framework Support neutral description of data (Part 20) Commonality of semantics because of neutral description Rule-based approach permits a variety of implementations –Example: for Part 21, XML implementations can be based upon DTDs, XML Schema, or custom code

26. 2004-10-0520944 Rationale Overview, F. Farance 26 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 20944 series: –Prototypical Uses (use cases for interoperability) –Implementation Variants (variety control) –Standards methodologies employed –General interoperability issues API Framework Coding Framework –Separation of Bindings –Separation of Identifiers –Separation of Terminology

27. 2004-10-0520944 Rationale Overview, F. Farance 27 Separation of Bindings Separates technologies from semantics Allows new technologies to be introduced over time Problems when they are kept together, e.g.: –HL7 was too tied to protocols Made data interchange difficult –OMG was too tied to CORBA (API/protocol) Missed out on XML technologies

28. 2004-10-0520944 Rationale Overview, F. Farance 28 A Framework for Harmonized/Consistent... Bindings: Codings, APIs, Protocols Encodings: Calling Conventions, Data Formats, Communication Layers Topic-Specific Informative Wording Topic-Specific Normative Wording Cross-Topic Codings: XML Cross-Topic APIs Informative Wording Cross-Topic APIs: Normative Wording Java, JavaScript, C/C++, Perl, Tcl, VB Various Standards Cross-Topic Protocols e.g.: Session Layers Various Standards Requirements Functionality Conceptual Model Semantics Bindings: CodingsBindings: Protocols Encodings: Various Communication Layers Encodings: Data Formats Bindings: APIs Encodings: Calling Conventions

29. 2004-10-0520944 Rationale Overview, F. Farance 29 Codings, APIs, Protocols — All Three Are Required Semantics Bindings: APIs Bindings: Codings Bindings: Protocols - Std APIs may be implemented via std or proprietary Protocols - Std Protocols may be accessed by std or proprietary APIs - Both std APIs/Protocols improve wide area interoperability - Std APIs may use std or proprietary Codings - Std Codings may be used by std or proprietary APIs - Both std APIs/Codings improve portable apps/data - Std Protocols may use std or proprietary Codings - Std Codings may be exchanged via std or proprietary Protocols - Both std Protocols/Codings improve system interoperability Harmonized standard APIs, Codings, and Protocols promote: - Application portability - Data portability - Multi-vendor, “open” solutions - Wide area, end-to-end interoperability Prioritizing The Development Of Standards for Codings, APIs, and Protocols

30. 2004-10-0520944 Rationale Overview, F. Farance 30 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 20944 series: –Prototypical Uses (use cases for interoperability) –Implementation Variants (variety control) –Standards methodologies employed –General interoperability issues API Framework Coding Framework –Separation of Bindings –Separation of Identifiers –Separation of Terminology

31. 2004-10-0520944 Rationale Overview, F. Farance 31 Separation of Identifiers Keep normative wording all in Part 81 Allows for use/reuse in other parts (URIs)

32. 2004-10-0520944 Rationale Overview, F. Farance 32 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 20944 series: –Prototypical Uses (use cases for interoperability) –Implementation Variants (variety control) –Standards methodologies employed –General interoperability issues API Framework Coding Framework –Separation of Bindings –Separation of Identifiers –Separation of Terminology

33. 2004-10-0520944 Rationale Overview, F. Farance 33 Separation of Terminology Keep normative wording all in Part 2 Simplifies mantenance

34. 2004-10-0520944 Rationale Overview, F. Farance 34 Conclusions Should provide more details on “Rationale” Implementers’ site created on SourceForge for open-source implementations of 20944