Separating Mapping from Coding in Transformation Tasks

Much of the power of XML is in the ease with which it can be transformed. Creating XML transformations in two separate tasks, Mapping and Coding, can not only maximize the skills of various team members, it can reduce development time and cost, and increase correctness of the finished code.

Outline:

Power of XML Transformations

• make your XML into someone else’s XML
• prepare XML for display (as HTML, PDF, or using any display engine)
• create other data formats, e.g., database load files
• in many ways, easy transformation is the engine behind XML’s success

XML Transformation Languages

• XSLT is premier tool for transforming XML
• other tools in use include perl, python, and Omnimark
• we use XSLT, but believe separating Mapping from Coding is advantageous regardless of the language used

What is a Transformation Map

• a complete & detailed functional requirement for a transformation
• a narrative description, in non-technical language, of the transformation
• a description of each type of information that appears in the target, and the path by which it gets there from the source

What a Transformation Map is NOT

• an executable program, or something from which a program can be automagically created
• pseudo-code
• compact

Why to write a Map (before writing the code):

• to isolate judgement calls, make them explicit and discussable
• to maximize subject matter expertise, especially when the subject matter experts have no programming skills
• to create a way that users/managers can check and monitor development and provide feedback
• to create a check point early in the development process when adjustments/corrections have minimum implact on cost and schedule
• to free the analyst to describe the desired transformation without self-limiting to things the analyst knows how to code

When to write a Map

• when the transformation is not trivial (“self-documenting”)
• when higher quality results will be rewarded
  • Better stylesheet
  • Better result documents
• when long-term maintenance will be required

Skills needed for Mapping and Coding are different

• skills needed for Mapping include
  • understanding both the source and target data
  • ability to articulate complex relationships clearly in ways that both programmer-people and content-owner people can understand
  • strong analytical skills
  • XSLT expertise is not required! (in fact, too much XSLT can be an impediment)
  • Some sense of how transformation work is helpful
• skills needed for coding include:
• principles and practices of transformation coding
• detailed knowledge of XSLT (or transformation language of choice)

Who uses the Map

• process owners and managers
• programmer creating the code
• QA person checking the code
• maintainers who debug/extend the code

An example Map

• a small, real, Map
• Source format is DHQ (a TEI variant)
• Target format is NLM Publishing
• Features of the Map:
  • “Pull” for metadata (structural mapping)
  • “Push” for document content (element-to-element mapping)

Using XML for the Map

• a natural application for XML
• allows development using familiar tools
• several display formats, including:
  • different levels of detail
  • change management markup
  • notes to self during Mapping
  • notes to coder from Mapper
• need to resist temptation to add endless bells and whistles

Summary

• separating two logically different tasks makes each easier and faster
• allows each to be done by people with appropriate skills without requiring that all people have all skills
• creates a mid-project check and adjustment point
• increases quality and maintainability of XSLT