Really Strategies Blog

Ecofont

Love the Dutch. The architecture, Gouda, Chocomel, public transportation, stroopwaffeln, open markets, I could go on for days.

Now I've learned the Dutch company, SPRANQ, created a free font that uses significantly less ink: the Ecofont. The font uses 20% less ink and in large corporations, this could represent a significant savings for daily printing. For my personal printing, it will make those expensive cartridges last longer. There is also a professional version available; though it is not intended for use in professional publishing and printing. A close-up of the font reveals its secret sauce---holes:

Ah, if only I had a big plate of pommes met mayo while installing the font...

Tropic of Cancer now sponsored by Viagra

On July 2, three inventors from Amazon filed two patents for including advertising in Kindle ebooks. Not that this is too surprising. I guess that's the compromise for all the benefits of ebooks: advertisements and marketing. I'll take my classics old school: hardbound and ad free.

What do you think about this?

Really Strategies Acquires SaaS XML Content Managment Platform DocZone.com

I am pleased to announce that Really Strategies has acquired SaaS XML content management platform DocZone.com. You can read the press release here. This is an exciting day for the team at Really Strategies for several reasons:

DocZone.com is known for its DITA-based SaaS content management solution with a Fortune 500 client base.
Our combined teams have the most experienced content management engineering team of any product vendor.
We are now better positioned to serve publishers and technical publishers on a global basis.
We now serve over 100 publishing companies, media companies, and technical publishing organizations.
DocZone and RSuite provide the market with a wealth of deployment options (SaaS, hosted, deployed, or build your own (using RSuite Engine). We feel this breadth of solution offerings is unique and is what differentiates us from the competition.

We are excited by the addition of DocZone.com and look to continue building on our past successes.

Really Strategies and RSuite at AAUP Annual Meeting

If you're heading into Philadelphia for the AAUP Annual Meeting this weekend, stop by table #27. We'll be there talking about

RSuite---a content management system for publishers
XML for publishing professionals---a 1-day workshop our consulting team offers
DITA for publishers---a new community project

We're also giving away free iPod Shuffles to the first 15 people who complete our content questionnaire.

When your XML is my XML

A number of times through my years at Really Strategies I’ve been asked to give an “intro to XML” type of presentation to a non-technical audience (usually business people or editors). I generally include a slide of some sort that says, “Your XML is not always my XML” to try to make the point that not all XML is the same. Many who are not technical and new to XML don’t initially know this. They think there is one XML format, not many flavors defined by many DTDs and schemas.

My slides usually contain some examples such as using <p> or <para> to indicate a paragraph. Or illustrating how different standards such as NLM, NITF, and RSS capture the author of the piece. Or pointing to three XML schemas for marking up recipe content. Where you say <tomato> I say <tomato>.

This is where DITA comes in to help. Because with DITA, you may have your XML and I may have mine but at the very least I should be able to understand the basics of your XML. I should be able to cut through your custom markup and still be able to make some sense of your content. DITA specializations allow for extending the base model, but DITA aware tools can still process specialized DITA content. Contrast that with the fact that if we modify NLM XML, it is no longer valid NLM XML.

And if the DITA for Publishing project takes off, we should be able to get to a time when there is a core set of domain-specific specializations, so at least journal publishers or magazine publishers or whoever will use a common set of specializations. There will always be publisher-specific specializations, but interchange (and sharing across domains) becomes easier.

Other standards won’t become irrelevant, but we should begin to think of them as delivery targets (which is how many of them were initially designed). Delivering NewsML feeds to your aggregators. Submitting NLM content to PubMed. Building an ePub format for eReaders. But using DITA behind that offers greater flexibility in doing what you want to do with the content and using DITA-aware tools that can process any DITA content.

And if we achieve that vision, your XML can still be your XML, and my XML will be my XML, but underneath it all we will be able to more easily understand, share, interchange and process all of it.

Society for Scholarly Publishing Annual Meeting

This week several of us from Really Strategies attended the SSP Annual Meeting. I was there until the "bitter" end when Richard Newman (AMA) and I did a skit to introduce the SSP IN Meeting.

The spirit was upbeat. The rooms were full. And, the Twitter activity was healthy. We just needed more power outlets.

The event was covered extensively on the SSP Blog, The Scholarly Kitchen.

If you didn't go this year, we hope to see you in San Fransisco for SSP 2010!

DITA For Publishers: New Community Project

Publishers are starting to take DITA very seriously and Really Strategies has been in the forefront of that trend as champions of Publishing requirements on the DITA Technical Committee and within the larger DITA community, as practitioners developing solutions and approaches for applying DITA to Publishing business problems, and as tool developers creating software solutions that support the Publishing use of DITA.

Out of the work that we've done over the last couple of years we have developed a number of basic Publishing-specific DITA components that are completely generic. We also started to realize that for Publishers to realize the maximum value from their use of DITA there would need to be a common starting point that Publishers could leverage, avoiding the need to re-invent things everyone needs. Eventually Publishers will need formal representation in the DITA standardization process, once there is sufficient Publishing community involvement.

To that end Really Strategies has sponsored the creation of a new community-based, open-source project: DITA For Publishers (dita4publishers.sourceforge.net).

The DITA For Publishers project is intended to provide a set of Publishing-specific DITA element types tailored to the task of representing typical Publishing documents, such as commercial fiction and non-fiction, magazines and other types of periodicals, travel and nature guides, and so on. These are documents that have fundamentally different content requirements and business processes compared to the technical documents to which DITA has traditionally been applied.

The DITA For Publishers project is still very new but it already provides some useful pieces any Publisher would need for a DITA-based XML system:

A Publishing-specific DITA map type: pubmap, designed to enable representation of all types of Publishing documents, including documents with arbitrary or idiosyncratic content organization
Basic Publishing-specific topic types for articles, book parts, book chapters, generic subsections, and sidebars. These topic types enable the natural and intuitive representation of most existing publications within a DITA context.
Publishing-specific support domain (mix-in element types) for representing the sort of arbitrary formatting requests that are an unavoidable reality of Publishing.
Basic extensions to the DITA Open Toolkit to support the Publishing-specific element types.
A new EPub-creating plugin to the DITA Open Toolkit that enables the creation of reader-ready electronic books from DITA-based content, with specific support for publication maps.
Sample Publishing-type documents that demonstrate how to use the DITA For Publishers element types. The first such sample is The Wonderful Wizard of Oz from Project Gutenberg, marked up as a pubmap and a set of chapter topics.
How-to information on how to apply DITA and DITA-based technology to common Publishing document types and business problems.

The materials are packaged for download and ready to be used with the latest versions of the DITA Open Toolkit and DITA-aware editors.

DITA For Publishers is a community project, which means it needs and depends on and welcomes involvement and contributions from the entire community of Publishers. Immediate needs for the project are:

Statements of requirements from Publishers: What information structuring challenges do you have that you would need or expect a DITA-based solution to solve?
Sample Publishing documents that can be used to test and demonstrate the DITA For Publishing specializations and supporting tools (see my free data conversion offer below).
Implementation support: there is always a need for programmers to contribute to the development of generic support components (transforms, etc.).

For Publishing document samples, my general offer is:

If you, the Publisher, will provide:

Electronic source and final form of one or more Publishing documents
An appropriate non-copyright license, such as a Creative Commons non-commercial license, for those documents as served by the DITA For Publishers project through the project's Web site (dita4publishers.sourceforge.net) (so that the DITA For Publishing project can make the source and rendered forms freely available for at least non-commercial use).

I will provide:

Conversion of the content to DITA-based XML using the Publishing For DITA markup as appropriate
The resulting XML back to you, the Publisher, with your original copyright retained, for you to do with as you will.
Such renditions as I can produce with the tools at hand (e.g., HTML, EPub, PDF using XSL-FO)

In the unlikely event I get inundated with samples, I retain the right to cry "uncle".

Note that this is an offer of free data conversion at the small cost of providing a non-exclusive, non-commercial-use license for the content. The value to the DITA For Publishing project is the chance to develop both a larger body of illustrative examples and practical experience with representing Publishing documents.

DITA North America Trip Report

I recently attended the DITA North America conference in St. Petersburg Florida. I was there to present a paper on our experience using the DITA Learning and Training module to develop an XML solution for test preparation publications.

As my and Really Strategies focus for DITA is how it applies to the needs of Publishers, I was pleased to see three different presentations (including my own) on using DITA for learning content.

Robin Sloan of PTC/Arbortext presented on how PTC uses DITA for their own training materials. What they did predated the development of the Learning and Training module and they contributed imporantant design aspects to the module. Robin's main message was that they were able implement a DITA-based process without too much difficulty and achieved significant savings and process improvements by doing so.

Patrick Quinlan and Alisha Carter of Citrix Systems presented on their experience moving from a DTP-based system for developing product training to a DITA-based system. They focused on the business drivers (saving process time and reducing translation costs) and the social aspects of the transition. They were able to implement the techology and meet their first-round time and cost saving goals. They talked in some detail about how they managed the roll out and training of their training development team so as to both grow support from the ground up and avoid backlash from trying to do too much too fast.

In my paper I focused on how the use of DITA in general, and the Learning and Training module in particular, allowed me to develop an XML solution in much less time than a traditional solution would have. Because the system I was developing had to enable publishing of the test prep publications as they are, I had to work out ways to capture all the arbitrary formatting and unavoidable variance inherent in these sorts of publications. An interesting aspect of this project was that the client did not ask for a DITA solution, they asked for an XML solution, and I realized that a DITA-based solution was the shortest path to the best solution.

While only three talks out of three day's of talks doesn't seem like much, it represents a significant increase in the amount of discussion being given to non-tech-doc applications of DITA and reflects what I'm seeing as an increasingly rapid adoption of DITA by Publishers of various sorts.

The new Learning and Training module has lots of obvious value for Publishers creating any sort of educational material but Publishers are starting to understand that DITA offers a lot of value as a base for any XML solution, whatever it is. For example, I am currently working with a professional association to develop a DITA-based solution for publishing magazines and books of all sorts. In this case, they specified the use of DITA to us, based on the sound recommendation of another consultant (the Rockley Group).

It would not suprise me if next year DITA North America includes, if not a Publishing track, at least one day focused on Publishing applications of DITA....

Why newspapers have failed

I by no means profess to know much about the newspaper industry. I read newspapers both online, and yes, in print, but that's about it. When it comes to analysis on the newspaper industry, I leave it up to the experts such as Ken Doctor who writes his analysis in the Outsell Insights daily newsletter.

I recently came across an article in the Columbia Journalism Review by Walter Pincus who writes for the Washington Post. His article - Newspaper Narcissism, Our pursuit of glory led us away from readers - is a very good read.

Some interesting facts from the article:

An average reader spends 25 minutes reading the print newspaper
There are 110 million daily readers of print newspapers
Consumers of online news generally read between 10AM and 4:30PM. Hmm, don't we all have a job to do? Pincus' point is that consumers who read online generally only have time to read headlines.

I didn't take away from this article that Pincus was some old guy complaining that it is not like it used to be but rather that the industry has taken the wrong approach over the past few decades. It is worth the time to read this article if you are interested in a good retrospective look at the newspaper industry.

DITA Keyref Example: Links from Glossary Entries

DITA 1.2, currently in the final stages of development by the OASIS DITA Technical Committee, provides a number of important new features. Of the new features in DITA 1.2, it can be argued that the key reference (keyref) feature is the most important. The keyref feature provides the ability to do indirect, context-dependent linking, something that is required in any application that supports re-use of content across multiple publications.

Because keyref is so important and because it also has inherent, unavoidable complexity, I will be posting short examples of how keyref can be used to solve specific business problems. This is the first in an occasional series of such examples.

This example shows one particular application of the keyref feature to a real-world problem faced by one of Really Strategies' clients. The data and the business requirements are real.

This is is a real-world example of using the new DITA 1.2 keyref feature to make existing content with topic-to-topic cross references reusable, using keyref, where without keyref is it not reusable.

The scenario comes from real publications: test preparation manuals for primary education standardized tests. For this client, one business goal was to define an XML solution that produced, as much as possible, publications that reflected their current, pre-XML presentation practices.

Each test prep manual publication consists of a set of lessons, pointed to by topicrefs within a publication-specific map.

Each publication also includes a glossary, where each glossary entry contains a cross reference to the lesson or lessons in which in the term is defined or explained. With DITA 1.1, these glossary entries use a normal <xref> element to point from the glossary entry to the topic for the appropriate lesson:

<glossentry
 id="action">
 <glossterm>action</glossterm>
 <glossdef>what a character does in a story 
 (<xref href="../lessons/lesson_12.xml"/>)</glossdef>
</glossentry>

This works to the degree that the cross reference will resolve to topic lesson_12.xml but it can only ever resolve to lesson_12.xml. This lesson is specific to a particular test prep manual, e.g., Texas TAKS Language Arts Grade 7.

However, the business requirement is that the glossary entries be re-usable across different publications. With the cross reference, the topic cannot directly be re-used in different publications (different maps) because the crossreference is a direct topic-to-topic reference: regardless of the map that uses the glossary entry, it will always point to lesson_12.xml.

In the DITA 1.1 the only DITA-defined options are:

Have publication-specific glossary entries that conref the definition text and contain publication-specific cross references.
Replace the cross references with reltable links.

Option 1, per-publication glossary entries with conref, requires many publication-specific glossary entry topics as well as the base glossary entries as well as the conrefs themselves. It works, but it's complication and duplicated data. It also requires explicit per-publication authoring of the cross references.

Option 2, reltable links, works, but either produces a presentation result that is not consistent with the pre-DITA publication practice (that is, the legacy presentation that we are attempting to replicate as closely as possible) or requires custom processing to make the presentation result look like a normal cross reference. The relationship tables eliminate the need for per-publication glossary entries, but do require separate per-publication authoring of the relationship tables, one or more rows for each glossary entry.

With DITA 1.2, there is a third solution that avoids both the need for per-publication glossary entries and the need for per-map relationship tables: keyref.

The keyref features provides an indirect addressing mechanism that allows a single reference to resolve to different concrete targets in different maps. Keys are defined on <topicref> elements. Linking elements, such as <xref>, refer to the keys using the new keyref= attribute rather than href=.

In the case of the glossary entries for the test prep manual, it is a business rule that every glossary entry have at least one corresponding lesson in which the glossary entry is defined or explained. This means that glossary entries can blindly point to the key for the lesson for the entry without knowing which lesson that will be in a given map. Within a publication-specific map, the topicref for each lesson simply defines the keys for those terms it defines or explains.

Using the approach, the glossary entry gets modifed to replace the href= on the <xref> element with a keyref=:

<glossentry
 id="action">
 <glossterm>action</glossterm>
 <glossdef>what a character does in a story 
 (<xref keyref="action_Lesson"/>)</glossdef>
</glossentry>

Note that instead of pointing to a key like "lesson_12", the key reflects the term itself, "action_Lesson", reflecting the requirement that there must be a lesson for the terms "action". In fact, you can take the uttering of the key as a demand that there be a lesson that defines "action." At a minimum, a keyref-aware processor will report any keys that can't be resolved, providing a built-in completeness check on the correlation of glossary entries to lessons.

Within the map for a given publication, the topicrefs to lesson topics are modified to add the keys for the terms they define or explain:

...
<topicref
 navtitle="Chapter 2. Literary Elements">
 <topicref
 navtitle="Character"
 href="ELA/TX_ELA_G7/lessons/lesson_13.xml"
 keys="action_Lesson"
 />
 <topicref
 navtitle="Setting"
 href="ELA/TX_ELA_G7/lessons/lesson_14.xml"
 keys="clause_Lesson setting_Lesson"
 />
 ...

Note that a given topicref can define any number of keys. In the case of the lessons, a given lesson might define or explain a number of different terms.

Because keys are defined within maps, a given key reference can resolve to different targets when resolved in the context of different maps.

For example, having created the Texas TAKS Language Arts Grade 7 test prep publication, we decided to create the Ohio Grade 8 Language Arts test prep publication. It's the same subject so most, if not all, of the glossary terms are appropriate, but the specific lessons will be different for this new publication.

By defining the same keys in the map for the Ohio publication, the same glossary entries can be re-used without modification in the new publication. The new map might look something like:

...
<topicref
 navtitle="Chapter 3. Literary Devices">
 <topicref
 navtitle="Plot"
 href="ELA/OH_ELA_G8/lessons/lesson_21.xml"
 keys="clause_Lesson"
 />
 <topicref
 navtitle="Character"
 href="ELA/OH_ELA_G8/lessons/lesson_22.xml"
 keys="action_Lesson"
 />
 <topicref
 navtitle="Setting"
 href="ELA/OH_ELA_G8/lessons/lesson_23.xml"
 keys="setting_Lesson"
 />
 ...

Here, the same keys are defined, but linked to different lesson topics.

Now there is exactly one glossary entry for each term, with no need to have publication-specific versions of each glossary entry. The cross references are just normal cross references, so they require no special processing. Likewise, there is no need for relationship tables.

The author of the publication-specific map still has to figure out which terms are defined in which lessons in the publication and declares the keys appropriately, but that work has to be done regardless: the only variable is how the results of the analysis are captured in the DITA markup.

For this particular use case, the keyref feature provides the simplest solution, in terms of data complexity while also allowing the use of xref, reflecting the legacy practice we need to preserve for this particular client.