This list contains the yet-unranked requirements/enhancements identified by the OASIS DITA Technical Committee for DITA 1.1 and future design work. Please assess what you consider to be your top 5 requirements and submit those Issue numbers to the DITA TC via the comment form: Send a Comment (1.1 requirements top 5). This review period opens on May 23 2005 and closes end of day June 6 2005 (2 weeks).
|Issue #||Issue Title||Description of proposal|
|1||Keyword (semantic)||Elaborate on the semantic role of keyword (issue of multiple meanings on this single name)|
|2||Keyword (nesting)||Extend by allowing keyword to nest (more conref and specialization options)|
|4||Use subset of OASIS xNAL standard for addresses||New language addition for address metadata (or extend via specialization)|
|5||Add ANSI warning labels as addition to the <note> element||Extend the existing enumerated @type for note for additional values. (or create a domain for the purpose)|
|6||Make @role (and other enumerated attributes) un-enumerated.||The issue is that the role="other" plus otherrole approach is only semi-extensible|
|7||Reconcile metadata elements in topics versus maps||In map.dtd, these elements have specific content restrictions that are not true in topics: shortdesc, searchtitle, linktext. Related to #12.|
|8||Allow <tm> to contain images or logoized content||Issue: tm content should be processible; is image consistent with this design principle? Is there a best practice instead for trademarked logo images or glyphs?|
|9||Specialize new DATA element from keyword||Design 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 element||For parallelism with the topic metadata (prototitle attribute)|
|11||Create elements for text attributes with translatable text||For the sake of translatability and reusability (neither easy to do with attribute content)|
|12||Consider making most universal attributes completely universal||Consistency issues, ease of maintenance (related to #7):
Add metadata attributes to table rows
|13||Create containers for steps and other elements||Enable specifying a range of peer targets|
|14||Specialize glossary entry and definition elements||Forum requests|
|15||Allow role names to be namespaced||Processing consideration|
|16||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|
|17||Conref improvements||Per deepdive #5:
Better judging of domain matching
|18||Move @format and @scope into rel-atts||Consistency for linking models|
|19||Introduce new, more general task type (between topic and task)||Popular request|
|20||Extensible metadata attributes||Design improvement to extend DITA attribute set; tactical methods needed for now|
|31||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)||Integration 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||Move <refsyn> to a domain (e.g. Programming or Software Domain)||(dependent on outcome of 32)|
|34||Replacement domain||Currently, 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.|
|35||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.
|36||Extensible 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.
|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!
|38||Bookmap / bkinfo revision||Validate the existing markup and make it formal ASAP to support FO activity in user community!
Note: Judged High Priority by the TC.
|39||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.
|40||Keyref architecture||The 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.
|41 (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.
|42 (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.
|43||Semantic (implicit) linking||There 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.
|44||Keep indextermref (or redefine its function)||Currently deprecated|
|45||Specialize See, See Also indexing elements.||Popular request|
|46||Allow substeps to be used as steps elsewhere||Popular request|
|47||Structured section||Issue is that section at the general level cannot constrain number and placement of titles; Constrain the core def? Specialize for structure?|
|48||Support change history and annotations in prolog||New prolog elements or specializations|