Rationale Overview, F. Farance 1 Rationale Overview For Series Frank Farance, Farance Inc

Rationale Overview, F. Farance 2 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 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

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 – –click on “Rationale” (third bullet)

Rationale Overview, F. Farance 4 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 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

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”

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”

Rationale Overview, F. Farance 7 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 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

Rationale Overview, F. Farance 8 Rationale for Series The 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)

Rationale Overview, F. Farance 9 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 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

Rationale Overview, F. Farance 10 Prototypical Uses of 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

Rationale Overview, F. Farance 11 Example Taken From Extracting a value domain from a metadata registry:

Rationale Overview, F. Farance 12 Example Of 20944, Then ISO 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 Metadata #1: ISO/IEC MDIB API

Rationale Overview, F. Farance 13 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 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

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

Rationale Overview, F. Farance 15 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 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

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

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)

Rationale Overview, F. Farance 18 ISO/IEC Family of Standards — Dependencies Among the Parts LDAP Protocol Binding Common Conformance Provisions General Usage Common Vocabulary Common Data Structures Semi-Structure Aggregation XML Coding Binding Common Coding Provisions DIVP Coding Binding ASN.1 Coding Binding PHP API Binding Common API Provisions C API Binding C++ API Binding Java API Binding ECMAscript API Binding Perl API Binding LISP API Binding ODBC Protocol Bindings DCTP Protocol Bindings SOAP Protocol Binding WSDL Protocol Binding JMS Protocol Binding Framework MDR Attribute Map Profile For MDR URIs For MDR Navigation Common Profiles Provisions Common Protocol Provisions

Rationale Overview, F. Farance 19 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 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

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

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”

Rationale Overview, F. Farance 22 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 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

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

Rationale Overview, F. Farance 24 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 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

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

Rationale Overview, F. Farance 26 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 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

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

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

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

Rationale Overview, F. Farance 30 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 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

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

Rationale Overview, F. Farance 32 Overview What is a “Rationale”? Why create one? Who uses them? Rationale for 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

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

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