2004-10-0520944 rationale overview, f. farance 1 rationale overview for 20944 series frank farance,...

2004-10-05 20944 Rationale Overview, F. Farance

1

Rationale Overview For 20944 Series

Frank Farance, Farance Inc.

[email protected]

+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






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

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






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






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

User

Portal Services/AppsWeb Access

UserInterface,Browser

Apps,Services

Info/Knowledge

Base

DataServer

Info/Knowledge

Base

DataServer

Queries (e.g. via web)

Information Exchange

Portal,FrontEnd

#3: DataExchange

#2: ISO/IEC 11179Metadata

#1: ISO/IEC 20944MDIB API


13






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






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-65LDAP Protocol

Binding

20944-03Common

ConformanceProvisions

20944-04GeneralUsage

20944-02Common

Vocabulary

20944-05Common Data

Structures

20944-06Semi-Structure

Aggregation

20944-21XML Coding

Binding

20944-20CommonCoding

Provisions

20944-22DIVP Coding

Binding

20944-23ASN.1 Coding

Binding

20944-47PHP APIBinding

20944-40Common

APIProvisions

20944-41C API

Binding

20944-42C++ APIBinding

20944-43Java APIBinding

20944-44ECMAscriptAPI Binding

20944-45Perl APIBinding

20944-46LISP APIBinding

20944-61ODBC Protocol

Bindings

20944-62DCTP Protocol

Bindings

20944-63SOAP Protocol

Binding

20944-64WSDL Protocol

Binding

20944-66JMS Protocol

Binding

20944-01Framework

20944-8111179-3 MDRAttribute Map

20944-82Profile For

11179-3 MDR

20944-83URIs For

11179-3 MDRNavigation

20944-80CommonProfiles

Provisions

20944-60CommonProtocol

Provisions


19






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

Maintenance

Development

Review

Amendments: 2-3 yearsRevisions: 4-5 years

ConsensusBuilding

User/Vendor/Institutional/

Industry“Extensions”

“Extensions” Become Input ToNext Revision Of Standard

Industry-Relevant,Widely-Adopted

“Extensions”

The “Standard”


22






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






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






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

Encodings: Calling Conventions, Data Formats, Communication Layers

Topic-SpecificInformative Wording

Topic-SpecificNormative Wording

Cross-TopicCodings: XML

Cross-Topic APIsInformative Wording

Cross-Topic APIs:Normative WordingJava, JavaScript,C/C++, Perl, Tcl, VB

Various Standards

Cross-Topic Protocolse.g.: Session Layers

Various Standards

Requirements

Functionality

Conceptual Model

Semantics

Bindings: Codings Bindings: Protocols

Encodings: VariousCommunication Layers

Encodings:Data Formats

Bindings: APIs

Encodings:Calling Conventions


29

Codings, APIs, Protocols —All Three Are Required

Semantics

Bindings: APIs

Bindings: Codings

Bindings: Protocols

- 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

- Std APIs may use std orproprietary Codings- Std Codings may be usedby std or proprietary APIs- Both std APIs/Codingsimprove portable apps/data

- Std Protocols may use std orproprietary Codings- Std Codings may be exchangedvia std or proprietary Protocols- Both std Protocols/Codingsimprove 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 OfStandards for Codings, APIs, and Protocols


30






31

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


32






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

2004-10-0520944 rationale overview, f. farance 1 rationale overview for 20944 series frank farance,...

Documents