Joe Gollner

Gnostyx Research Inc.

jag@gnostyx.com

www.gollner.ca

@joegollner

A Guide to XML

Content Standards

A Guide to XML Content Standards

• Some Initial Case Studies

• Thinking about Standards • Fundamentals

• Evaluating Standards

• Implementing Standards

• Hazards

• Conclusions

• FUSION

Case 1: Faux Standardization

• Legal Sector (1999 – 2001)

• Requirement:

Digital Evidence Interchange

amongst courts and case

participants

• Potential References:

LegalXML initiative (OASIS)

• Discovery:

• Standards barely emergent

• Focused on small problems

• Untested in implementations

• Heavily influenced by a

small group of tool vendors

Case 2: Standardization by Edict

• Energy Sector (1993 – 2003)

• Requirement:

Interchange protocol for

applications, interventions & cases

• Regulatory Agencies

Adopted set of core technical

standards to develop an

interchange standard along with

associated process guidelines &

applications

• Result:

Unusable protocol, unintelligible

process & unstable applications Complete failure of initiative

Case 3: Standards in Action - A Success Story

Standardization enabling

efficient global trade

Thinking about Standards

• The Hard Truth about Standards

“The wonderful thing about standards

is that there are so many of them to choose from”

Rear Admiral Grace Murray Hopper

(Amazing Grace) US Navy

• She was one of the first Programmers (Harvard Mark I)

• She is credited with writing the first program compiler

• She found a moth in a relay in the Mark II calculator and hence

passed the term “bug” into computing terminology

• Important Point

• Grace Hopper was focused on accomplishing things

• Standards were something chosen – as a means to an end

What do we mean by “Standard”?

• The word “Standard”

• Descends from Middle English for

“a flag raised on a pole as a rallying point”

• Shortening of “estendart” from

Old French for “extend”

• Common uses of the word “standard”

• an agreed level of quality or attainment

• something used as a measure, norm or

model in comparative evaluations

• principles of conduct informed by notions of

honor and decency

• accepted as normal or average

• not special or exceptional Source: OED

The Objective of Standards

• Enabling Interoperability • Opportunity Realization

• Risk Minimization

• Cost Reduction

• Key Domains • Information Interchange

• Process Coordination

• Technology Integration

• Standards Lifecycle • Emergence

• Maturity

• Retirement

Evaluating Standards

• Independence • From parochial interests, proprietary claims, external influences

• Formality • Of creation, validation, approval & modification process

• Stability • Of standard over time & the backward compatibility of changes

• Completeness • Sufficiency for declared scope as well as availability of

useful documentation & reference implementations

• Adoption • Extent of support amongst tool vendors, authorities & users

• Practicality • The extent to which all, or parts, of the standard can be deployed

Evaluating Standards: Example 1

• Summary • International

standard

• Esoteric

• Small stakeholder

community

• Mature

• Disuse

leading to

retirement

• Approach • Harvest knowledge

& tools to reuse with

newer standards

SGML

Evaluating Standards: Example 2

• Summary • W3C Recommendation

• Enabling important

delivery capabilities

• Solid stakeholder

community

• Emergent

• Adoption

leading to

maturity

• Approach • Participate in standard

• Leverage & plan to

expand use

HTML5

Evaluating Standards: Example 3

• Summary • Industry specification

• Broad scope

• Specialized stakeholder

community

• Continuously

changing

• Evolving as

a shared solution

• Approach • Implement when

absolutely necessary

• Address known

risk areas

S1000D

Independence Practicality

Adoption

CompletenessStability

Formality l

l

l

l

l

l

l

l

l

l

l

l

Issue 4

Issue 3

S1000D

Evaluating Standards: Example 4

• Summary • Cross-industry

standard

• Seeking shared &

support approach to

key CM issues

• Active community

• Strong

vendor

adoption

• Approach • Plan for adoption

to leverage core

capabilities & tool

support

DITA

l

l

l

ll

Independence Practicality

Adoption

CompletenessStability

Formality

l

l

l

l

l

ll

Version 1.1

Version 1.2

DITA

Selecting Standards

• Considerations

• Applicability to requirements

• Level of adoption

within your industry sector

• Extent of vendor support

• Community activity level

• Sought After Benefits

• Knowledge Acquisition

• Solution Acceleration

• Uniqueness Avoidance

• Vendor Support

• Industry Alignment

• Stakeholder Diversification

Implementing Standards

• Standards

• Incorporated into solutions

• Deliberately

• Methodically

• Appropriately

given the focus of the standard

• Included under

configuration management

• Version changes handled

like product version changes

• Evaluation & testing

• Dependency monitoring

• Assessment of alternatives

• Potentially deployed in concert (two or more implemented to leverage relative strengths)

For Example: Using DITA to Implement S1000D?

• DITA can be leveraged as a tool

• To define and tailor precisely specialized information types that help authors produce the required content

• Adaptations can be made to handle unique equipment requirements

• Adaptations can be made to handle legacy or parallel requirements that are not addressed in S1000D (nor should be)

• Application architecture can be streamlined while also improving the precision & value of the content

• Can lead to a better, more up-to-date Common Source Data Base (S1000D CSDB)

Hazards: The Standards Wars

• Standards are like sausages

• If you love them, don’t watch

them being made…

• One reason formality

is important

• Standardization is a key

competitive battleground

• Why adoption is important

• Broad adoption is a sign

• The competition is over

• The focus of competitive forces

has moved elsewhere

Hazards: Mistakes & Warning Signs

• Common Mistake: Confusing Standards for Solutions • Believing standards alone will solve problems

• Stretching standards to address all solution requirements

• Fixating on the reference implementations

• Focusing more on standards than on actual solutions

• Hoping that standardization will eliminate change

• Hoping standards will erase responsibility

• Warning Signs: Excessive complexity & change • Sprawling scope covering several domains

• Continual emergence of changes especially

• Non-backwards compatible changes

• Changes driven by narrow application demands

• Appearance of hyper-specialized products

Conclusions about XML Content Standards

• What do we take away from all this?

• Standards • are agreements formed by communities

• are intended to facilitate interoperability

• can be applied to information, technology and practices

• should result in improved quality and cost-effectiveness

• What does this really mean? • standards are primarily important to collaborating enterprises

• standards help avoid unnecessary effort and expense

• standards enable constructive competition

• standards must enable & not obstruct improvement & innovation

• standards are not an end in themselves

A Guide to XML Content Standards

• FUSION (1993) • Focused

• Use of

• Standards for

• Integrating

• Organizations and

• Networks

• A sensible posture • Place the solution on top

• Deploy standards

• To achieve solution goals

• To realize the intrinsic potential manifest in good standards

• Leverage standards,

don’t be enslaved by them

• Be an active part of the

standards community as a

way to learn and as a way to

share what you have learned

Making Connections

Joe Gollner

Gnostyx Research Inc.

www.gnostyx.com

jag@gnostyx.com

Twitter: @joegollner

Blog: The Content Philosopher

www.gollner.ca