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.
|Ranking||Issue #||Issue Title||Description of proposal|
|Extensible metadata attributes||Design improvement to extend DITA attribute set; tactical methods needed for now|
|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.
|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 +||45||Specialize See, See Also indexing elements.||Popular request|
|2||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)|
|2||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.|
|2||11||Create elements for text attributes with translatable text||For the sake of translatability and reusability (neither easy to do with attribute content)|
|2||12||Consider making most universal attributes completely universal||Consistency issues, ease of maintenance (related to #7):|
Add metadata attributes to table rows Add @id and @conref to all Add @outputclass to linkinfo, linktext
|3||13 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|
|3||46 (related to "new task")|
|Allow substeps to be used as steps elsewhere||Popular request|
|Keyword (semantic)||Elaborate on the semantic role of keyword (issue of multiple meanings on this single name)|
|Specialize glossary entry and definition elements||Forum 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 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.|
|1||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.
|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 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.
|1||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.
|1||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.
|Structured section||Issue 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 prolog||New prolog elements or specializations|
|`||2||Keyword (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)|
|`||6||Make @role (and other enumerated attributes) un-enumerated.||The issue is that the role="other" plus otherrole approach is only semi-extensible|
|`||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)|
|Allow role names to be namespaced||Processing consideration|
|`||18||Move @format and @scope into rel-atts||Consistency 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)Major||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 depends on 32||Move <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) 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|
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.