Some candidates for DITA 1.1

[Erik Hennum <ehennum@us.ibm.com>]

Esteemed DITA Technical Committee:


While DITA 1.0 was cooking, we've keep a few thoughts on ice that we'd like to defrost for consideration and discussion.


* Support for foreign content vocabularies such as MathML and SVG

Some content types have generally accepted vocabularies such as MathML (Mathematics Markup Language) and SVG (Scalable Vector Graphics). Instead of reinventing the wheel, DITA might allow optional use of these well-known vocabularies through specialization. That way, people who don't need them don't have to include them while people who do need them can have broad interoperability on the basis of the established vocabulary.

The specific proposal is to introduce a DITA <unknown> element with a content model that allows any content. Specializers can then specialize the root elements of foreign vocabularies from this <unknown> element. The default behavior of the <unknown> element might be to process the content of any child <section> element. That way, the specializer can provide a specialized <section> element that provides textual content to be used in place of the foreign content, thereby preserving the intelligibility of the topic when sent to a DITA adopter who isn't using the foreign vocabulary.


* Extensible metadata by expressing data in map structures

Through the combination of the recursive topicref element and specialization, the DITA map makes it easy to build up complex but semantically precise topic structures. The same mechanisms could serve equally well to define metadata about topics. Through the DITA reference, collection-type, and relationship table mechanisms, such metadata structures could be applied to many topics.

The specific proposal is to add a value attribute to the topicref element so it can be specialized and nested to represent metadata.


* Reconciling topic <link> and map <topicref> elements

In DITA 1, a topic expresses a link with a different element than a map. As a result, authors can't copy and paste between topics and maps, specializers have to define two elements with the same semantic but different content models, and everyone including process writers must understand two models. If we could find a way to represent links in topics with topicrefs, that would simplify the story all around.

The specific proposal is to allow a <topicref> element in the <related-links> element. The referenced topics would be processed as related to the containing topic. In addition, the proposal is to add <relcontext> and <thisTopic> elements. The <linkcontext> element specifies a set of topics related to the current topic and the current topic specifies its position within the context. The following example represents a set of hierarchical relationships:

<relcontext collection-type="sequence">
<topicref href=""parent.dita"> <topicref href=""priorSibling.dita"/> <thisTopic>
<topicref href=""firstChild.dita"/> ...
<topicref href=""lastChild.dita"/> </thisTopic>
<topicref href=""nextSibling.dita"/> </topicref>
</relcontext>

For comparison and contrast, we should provide such cases through both the existing link element and the proposed topicref element.


* Policy-based style

If DITA 1.1 provides better support for books (for instance, through a bookmap specialization), it will become important to specify styling for the book. To maximize the reuse of both the content and the style policy, it will be important to keep those style definitions separate from the topic content and the map context.

One approach would be to define style policies in a separate file and require processes to apply the specified style policies to content. Style policies might be matched to content based on a combination of the semantics declared through by element specialization and the output class attribute and the identity of a map context or of topic content as specified by id attributes and filenames.


* Integration of domain elements with structural elements of the topic

Currently, domains make it possible to introduce new elements that can be substituted for base elements in any other topic type. A specialized topic type cannot, however, specify domain elements in content models, nor can domain elements specialize the structural elements of topic types. For instance, a designer can specialize the <apiname> element with a <javaclass> element but cannot use that <javaclass> element in the content models of javaPackage, javaField, and javaMethod topic types.

The most general strategy would be to try to decouple the packaging of modules from the element inheritance hierarchy so that the base element could reside in a topic or domain module or even the same module so long as the base element had the appropriate content model and semantics. Any solution must continue to support inherited processing, generalization and respecialization, and conref and authoring simplicity.



Hoping that's interesting,


Erik Hennum
ehennum@us.ibm.com


PS. By the way, I'll be presenting a summary of DITA and DITA domain specialization at the OASIS Symposium on the Future of XML Vocabularies.