This presentation was provided by Kim Breitfelder of IEEE during the NISO event, XML for Standards Publishers, held on Monday, April 24, 2017 in Washington DC.

1. Incorporating XML into a Standards
Environment: False Starts, Successes,
and Challenges
Kim Breitfelder,
IEEE-SA Director of Content, Production & Management
NISO XML for Standards Publishers Symposium
LoC, Washington, DC
24 April 2017

2. 2
IEEE:
World’s Largest Professional Association
Advancing Technology for Humanity
430,000+
Members
1,300+
Annual Conferences
190+
Countries
45
Technical Societies
160+
Periodicals
Our Global Reach
Our Technical Breadth
3,600,000+
Technical Documents

3. IEEE Standards Association
Global standards sustain products and services for implementation and
use by customers in a globalized world
§ Aerospace Electronics
§ Broadband Over Power Lines
§ Broadcast Technology
§ Clean Technology
§ Cognitive Radio
§ Design Automation
§ Electromagnetic Compatibility
§ Green Technology
§ LAN/MAN
§ Medical Device Communications
§ Nanotechnology
§ National Electrical Safety Code
§ Organic Components
§ Portable Battery Technology
§ Power Electronics
§ Power & Energy
§ Radiation/Nuclear
§ Reliability
§ Transportation Technology
§ Test Technology
3
Examples:

4. IEEE-SA Content Production & Management
§ Over 1,100 active standards
§ Team of seven, augmented by ICs
§ Publish about 120 standards/year
§ 5 – 5000+ pages; typically about 100 pages
§ Support 500 active working groups
§ Knowledge of standards developing process (consensus, risk, legal)
§ Standards professionals who do publishing vs. publishing professionals
who do standards
§ NOT a part of IEEE Publishing (journals, transactions, etc.); coordination
between the two groups.
§ Compatibility with IEEE Xplore.
§ A very small part of IEEE published content, but vitally important.
6

5. Questions
─ What factors make a standards authoring and publishing environment
unique?
─ How do those factors ultimately dictate our choice of XML tools and
workflow? What works? What doesn’t?
5

6. Variability in just about everything
¾ Volunteer author base
− Divergent skill set—everyone one from people one step removed from
a typewriter to computer geniuses.
− “Boutique publisher” expectation; e.g., “I know your style is X, but my
document needs Y.”
− Vying for limited resources; e.g., “My document is more important
than others.”
¾ Subject matter
− A power engineering standard is very different from a software
engineering standard.
¾ Length
− 5 pages to 5000+ pages.
6
Additional factors
¾ Round trip for revision.
¾ Unique nature of a standards environment: Are we publishing
professionals or standard professionals?

7. Three XML workflow options (we tried ‘em all!)
¾ XML Last: Post-production conversion to XML
¾ XML First: Content is created in XML environment
¾ XML Middle: XML created sometime during production
7

8. XML Last
¾ Post-production conversion to XML
– Began in the 1990s (SGML) with an in-house DTD
– Created “just in case”
– Legacy conversion in 2015
Pros:
– Relatively easy once the DTD is written, the vendor is set up, etc.
– No impact on volunteers
– Little impact on most staff
Cons:
– The XML is always later
– No ability for single source publishing
– Quality may not be high
– QC is resource intensive
8

9. XML First
¾ Volunteers author in an online, collaborative XML environment
with a stripped down DTD
Pros:
– Conceptually beautiful: Cloud-based CMS and XML editor
– Enforces style
– Provides good quality XML
– Round trip problem completely goes away
– Frees us all from MS Word
– Suitable for single source publishing
Cons:
– Expensive—highly customized
– Complex; many moving pieces
– Limits of current technology
– Unreasonable expectation on volunteers
– Steep learning curve for staff
– Huge burden on staff to train volunteers
– Volunteer desire for exceptions in a system that dislikes exceptions
9

10. XML Middle. The “Just Right” solution
¾ XML Middle: XML created sometime during production
Ø Transparency: We chose the eXtyles solution
Pros:
– Minimal impact to volunteers (can author in MS Word)
– Allows round trip document to be returned for revision
– Good quality XML
– Allows for single source publishing
– Updated, modernized tools and skills (“We’re not in the stone age anymore!”)
– A solid, manageable move forward
Cons:
– Steep learning curve for staff—not always seeing the “big picture;” new tools;
heightened rigidity in style
– Emphasis from making the document look good to adding structure
– Software snafus
– Volunteer desire for exceptions in a system that dislikes exceptions
– Round trip return document needs improvement
10

11. 11
Questions?