Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Joe Gollner
Gnostyx Research Inc.
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
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
Twitter: @joegollner
Blog: The Content Philosopher
www.gollner.ca