DITA TC 1.1 Requirements for public review and ranking

Tally and ranking from public review - June 14 2005

Ranking process: I tallied each vote by its number, then totalled the votes per item, then sorted by highest value. The + characters indicate either an extra beyond the 5 requested, or an independent mention in the forum--use as weighting indicators.

We can use the "Candidate Release" mechanism to provide bug fixes and enhancements periodically, so that users are not waiting on point releases to get critical fixes.


  1. Note that the gap between 20 and 31 is really due to a manual renumbering mistake--I skipped the "2" key in the 10s column. There is no meaning to the sequence in these values; they are just IDs for referencing the items.
  2. Three members provided public comment votes (Wong, Hackos, Baril), which I take to indicate priorities rolled up from within their organizations.
  3. Based on IBM's 5-year experience with DITA, Michael provided a list of items felt to be relatively major in scope. These are not prioritizations, but rather a hint to the TC about the relative complexity of some of the issues--spread them across CRs. These are indicated in the Issue # column.
  4. One new requirement was written in, listed as #49. Upon review, it is not a TC language requirement, but rather an applicable comment for the DITA Open Toolkit.


RankingIssue #Issue TitleDescription of proposal


Extensible metadata attributes Design improvement to extend DITA attribute set; tactical methods needed for now
4 ++38


Bookmap / bkinfo revisionValidate the existing markup and make it formal ASAP to support FO activity in user community!

Note: Judged High Priority by the TC.

2 +37


Reconciling topic <link> and map <topicref> elements

In DITA 1.0, 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, etc..

The specific proposal is to allow a <topicref> element in the <related-links> element.

Note: Appears to be high risk/high cost wrt transforms!

2 +45Specialize See, See Also indexing elements.Popular request
25Add ANSI warning labels as addition to the <note> elementExtend the existing enumerated @type for note for additional values. (or create a domain for the purpose)
27Reconcile metadata elements in topics versus mapsIn map.dtd, these elements have specific content restrictions that are not true in topics: shortdesc, searchtitle, linktext. Related to #12.
211Create elements for text attributes with translatable textFor the sake of translatability and reusability (neither easy to do with attribute content)
212Consider making most universal attributes completely universalConsistency issues, ease of maintenance (related to #7):
Add metadata attributes to table rows
Add @id and @conref to all
Add @outputclass to linkinfo, linktext
313 related to 17


Create containers for steps and other elements Enable specifying a range of peer targets


Conref improvements Per deepdive #5:
Better judging of domain matching
Metadata reuse across topics and maps
Generalization on the fly


Introduce new, more general task type (between topic and task) Popular request
346 (related to "new task")


Allow substeps to be used as steps elsewherePopular request


Keyword (semantic)Elaborate on the semantic role of keyword (issue of multiple meanings on this single name)


Specialize glossary entry and definition elementsForum requests


Extend the link syntax to allow for indication of the use context for a link target To clarify problems related to links and re-use


Replacement domainCurrently, the logic of domain specialization means that an element specialized in a domain cannot be prevented from appearing in a DTD everywhere where the ancestor/inherited element can occur. Domain specialisation is powerful, but it would be more useful in practice with an exclusion capability, so that not all the elements would automatically be inherited in all valid locations.
136Extensible metadata by expressing data in map structures

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



Policy-based style mechanism

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.



Keyref architectureThe keyref attribute is intended to provide a key-based referencing scheme, with a level of indirection to allow for remapping of targets when content is reused in contexts where the target is unavailable.

Note: Judged by TC to be a complex issue.

141 (see 42)

Allow expanding the shortdesc model.

Sometimes the existing content model is insufficient; there are times when the opening paragraph needs to contain a list for example.

Note: Has processing implications.

142 (see 41)

Allow contracting the shortdesc model.

Conversely, there are times when the opening paragraph of content is already too long for use as hoverhelp/link previews.

Consider providing a marker element within shortdesc to allow authors to define a particular sentence within the shortdesc for use in hoverhelp, without affecting the shortdesc's function as first paragraph of content in other contexts.



Structured sectionIssue is that section at the general level cannot constrain number and placement of titles; Constrain the core def? Specialize for structure?


Support change history and annotations in prologNew prolog elements or specializations
`2Keyword (nesting)Extend by allowing keyword to nest (more conref and specialization options)


Use subset of OASIS xNAL standard for addresses New language addition for address metadata (or extend via specialization)
`6Make @role (and other enumerated attributes) un-enumerated. The issue is that the role="other" plus otherrole approach is only semi-extensible
`8Allow <tm> to contain images or logoized contentIssue: tm content should be processible; is image consistent with this design principle? Is there a best practice instead for trademarked logo images or glyphs?
`9Specialize new DATA element from keywordDesign change intended to enable core semantic identification of a structure that can be specialized in many ways for data structures.
`10 (see next)Navtitle as elementFor parallelism with the topic metadata (prototitle attribute)


Allow role names to be namespaced Processing consideration
`18Move @format and @scope into rel-attsConsistency for linking models


Side-by-side implementation of DITA ids and xml:id Resolve differences between standard W3C methods and DITA's current processing-enforced model.
`32 (is pre req for 33)MajorIntegration of domain elements with structural elements of the topic

The most general strategy would be to try to decouple the packaging of modules from the element inheritance hierarchy...

`33 depends on 32Move <refsyn> to a domain (e.g. Programming or Software Domain) (dependent on outcome of 32)


Support foreign content vocabularies such as MathML and SVG

The specific proposal is to introduce a DITA <unknown> element with a content model that allows any content.



Semantic (implicit) linkingThere are cases where semantic, phrase-level markup in DITA content has clear equivalents in topic-level markup.

Note: Judged by the TC to be a higher priority.

`44Keep indextermref (or redefine its function)Currently deprecated

It would be good if the actual markup elements (eg HTML/XHTML/XSL-FO elements) produced by the DITA stylesheets could be separated from the XSLT logic a bit more.

write-in by Anton Douche'

This could be somewhat related to issue 39, but I couldn't quite be sure.

We would like to customise the output markup, but the XSLT processing logic can be quite involved and editing them directly puts you at a disadvantage when it's time to merge in upgrades to the stylesheets when a new DITA toolkit is released.

One related process that could possibly be used to base this separation on is the localisation of strings. Of course localising strings seems much easier than localising the output markup.