Rationale Overview For 20944 Series

1
Rationale Overview For 20944 Series

• Frank Farance, Farance Inc.
• frank_at_farance.com
• 1 212 486 4700

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
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
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
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 arent obvious to outsiders
• Can help document future issues
• Outside of standards work
• Also used in software development, typically
  called design rationale

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 gt6000 hits
• rationale iso standard

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
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
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
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
Example Taken From 20944-01

• Extracting a value domain from a metadata
  registry

12
Example Of 20944,Then ISO 11179 Metadata
Exchange,Then Data Exchange
Portal Services/Apps
Web Access
Portal,FrontEnd
Queries (e.g. via web)
Information Exchange
1 ISO/IEC 20944MDIB API
3 DataExchange
2 ISO/IEC 11179Metadata
?
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
Implementation Variants(Variety Control)

• Standard describes what, not how
• Need to support a variety of implementations
• Low performance and high performance
• Shouldnt 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
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
Standards and MethodologiesEmployed

• 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
Standards and MethodologiesEmployed

• 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
ISO/IEC 20944 Family of Standards Dependencies
Among the Parts
20944-01Framework
20944-03CommonConformanceProvisions
20944-04GeneralUsage
20944-02CommonVocabulary
20944-05Common DataStructures
20944-06Semi-StructureAggregation
20944-21XML CodingBinding
20944-20CommonCodingProvisions
20944-22DIVP CodingBinding
20944-23ASN.1 CodingBinding
20944-47PHP APIBinding
20944-40CommonAPIProvisions
20944-41C APIBinding
20944-42C APIBinding
20944-43Java APIBinding
20944-44ECMAscriptAPI Binding
20944-45Perl APIBinding
20944-46LISP APIBinding
20944-65LDAP ProtocolBinding
20944-61ODBC ProtocolBindings
20944-62DCTP ProtocolBindings
20944-63SOAP ProtocolBinding
20944-64WSDL ProtocolBinding
20944-66JMS ProtocolBinding
20944-60CommonProtocolProvisions
20944-8111179-3 MDRAttribute Map
20944-82Profile For11179-3 MDR
20944-83URIs For11179-3 MDRNavigation
20944-80CommonProfilesProvisions
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
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
Building Standards InSeveral Steps
User/Vendor/Institutional/IndustryExtensions
The Standard
ConsensusBuilding
Development
Industry-Relevant,Widely-AdoptedExtensions
Review
Maintenance
Amendments 2-3 yearsRevisions
4-5 years
Extensions Become Input ToNext Revision Of
Standard
?
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
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
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
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
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
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
A Framework for Harmonized/Consistent
...Bindings Codings, APIs, ProtocolsEncodings
Calling Conventions, Data Formats, Communication
Layers
Topic-SpecificInformative Wording
Topic-SpecificNormative Wording
Cross-TopicCodings XML
Various Standards
Cross-Topic APIsNormative WordingJava,
JavaScript,C/C, Perl, Tcl, VB
Cross-Topic Protocolse.g. Session Layers
Cross-Topic APIsInformative Wording
Various Standards
?
29
Codings, APIs, Protocols All Three Are Required
- Std APIs may be implemented viastd or
proprietary Protocols - Std Protocols may be
accessedby std or proprietary APIs- Both std
APIs/Protocols improvewide area interoperability
Semantics
Bindings APIs
Bindings Protocols
- Std APIs may use std orproprietary Codings-
Std Codings may be usedby std or proprietary
APIs- Both std APIs/Codingsimprove portable
apps/data
Bindings Codings
- Std Protocols may use std orproprietary
Codings- Std Codings may be exchangedvia std or
proprietary Protocols- Both std
Protocols/Codingsimprove system interoperability
Prioritizing The Development OfStandards for
Codings, APIs, and Protocols
?
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
Separation of Identifiers

• Keep normative wording all in Part 81
• Allows for use/reuse in other parts (URIs)

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
Separation of Terminology

• Keep normative wording all in Part 2
• Simplifies mantenance

34
Conclusions

• Should provide more details on Rationale
• Implementers site created on SourceForge for
  open-source implementations of 20944