Dita Wiki
DITA 1.3 Proposals
Contents
In order to become a part of DITA 1.3, any proposal must pass through the Complete approval process
Beginning January 3, 2011, we are splitting this page into several pages to help manage proposals as they pass through the approval process. The following proposals are still in progress:
DITA 1.3 Triage list contains items that still need to be discussed for the first time.
DITA 1.3 - ready for full proposal contains features that need a proposal document filled out, or are waiting for review and approval to move to Phase 3
DITA 1.3 - ready for final proposal (with specification language) contains features that are awaiting final specification language, or are waiting for final review and approval
Deferred items contains items that have been deferred to a later DITA release
Dropped items contains items that have been withdrawn by the owner, or dropped due to lack of interest
For reference:
DITA template for 1.3 proposals: http://www.oasis-open.org/apps/org/workgroup/dita/download.php/41578/1-3template.dita
Note: We need to move strictly documentation issues from this page to the correct Wiki page. See http://wiki.oasis-open.org/dita/DocIssuesDeferredtoDITA1.3. Eberlein, 7 March 2011]
- For each item, on any page, the approval column should link to the minutes where the item was approved.
Treat as a bug fix; no need for full proposal
Items in this section are considered minor items that do not require a proposal document. These items are all approved for inclusion in DITA 1.3.
# |
Owners / Champions / Sub-committee |
Requirement, links to final proposal, any amendments, or notes |
Resolution |
13021 |
Yeo |
Processingrole attribute for relationship tables: We have a %topicref-atts-no-toc; attribute set which is identical to %topicref-atts; except that the former does not provide a default for the toc attribute. The most important element using %topicref-atts-no-toc; is <reltable>. It is not sufficient for <reltable> to have toc="no". The <reltable> element should have processingrole="resourceonly". I recall a bug in either the OT or the Idiom plugin, in which if a map contained a relationship table, all topics referenced by the reltable would appear in full at the location of the reltable in PDF output. Of course this is what nobody wanted or expected, but it is a predictable outcome of processing @toc following the letter of the DITA spec. Should we fix this problem by giving <reltable> a processingrole="resourceonly" value? Should we create a new %topicref-atts-no-localdisplay; attribute set? |
7/26/2011: Treat this as a fix |
13045 |
Joseph |
Revisit location in DTD where metadata elements are declared. See my definition of the issue in my email to the list, which received no response at the time: http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/200912/msg00147.html |
8/2/2011: Treat as documentation bug |
13049 |
Grosso |
Now that xml:lang has been added to the "dita" tag in DITA 1.2, we should consider if dir and/or translate should also be added. (I don't think translate should, but I wonder about dir.) |
8/2/2011: Treat as bug fix. |
13054 |
Yeo |
Make @href optional for <glosssymbol> and <hazardsymbol> elements. We made @href optional for <image> because @keyref can be used instead of @href. We probably forgot to do the same for specializations of <image>. |
9/20/2011: Treat as bug fix |
13055 |
Yeo |
Consider making <reqconds> and <reqpers> elements derive from UL, not OL. |
9/20/2011: Bug fix item |
13062 |
Yeo |
Improve this topic in the language reference: http://docs.oasis-open.org/dita/v1.1/OS/langspec/common/id-atts.html. Currently this says that @id is of type NMTOKEN, which is only partly true. @id is sometimes of type NMTOKEN and sometimes of type ID. The language reference should say that. |
9/20/2011: Add to quick-fix. |
13064 |
Yeo |
Improve documentation: The Architectural Specification (2.1.4.4.4) contains examples of constraint modules that do not work as they are currently written, because they do not include definitions of the entities that are used in the module. There isn't a "..." in the examples to indicate that anything is missing, and the text of the spec doesn't mention the need to define entities either. People will be confused if we don't make the need to define entities a lot more explicit. |
10/4/2011: Add to "bug fix" list |
13065 |
Yeo |
Change the spec's references to the "solidus" character to say "slash" instead. Developers generally understand what a slash is. Few have heard of a solidus. The term "solidus" is ambiguous as Unicode's definition is different from long-established typesetting terminology (http://en.wikipedia.org/wiki/Solidus_(punctuation). We could, if we feel the need, include the Unicode character for "slash" in an appendix. |
10/4/2011: Treat as bug fix. No need to define "slash". |
13066 |
n/a |
Allow <msgph> within <msgblock>, or possibly allow <ph> which will automatically bring in msgph and other phrase domain elements. Based on comment noted on dita-users. |
10/4/2011: Treat as bug fix. |
13080 |
Anderson |
Hopefully a "fix" type issue: make the vrm elements optional instead of required in prodinfo. Currently, if using or specializing prodinfo, a vrm element (with a version attribute) is required, even if only trying to specify a product name. |
10/11/2011: Treat as fix |
13068 |
Yeo |
Say that if a topicref points to one topic in a file, a processor may include only that one topic in output. This is what people expect. |
10/18/2011: Treat as documentation fix |
13073 |
Yeo |
Clarify in documentation: In <topichead> and <topicgroup> elements, does the @locktitle attribute do anything? See http://lists.oasis-open.org/archives/dita/201104/msg00010.html. The spec should say explicitly that attribute x on element y has no defined purpose. Otherwise, we're making the user think about what possible uses an attribute could have, and then reaching the correct conclusion that there is no purpose via the process of growing weary of thinking about it. |
10/18/2011: Treat as doc fix / update. |
13083 |
Eberlein |
Correct spec in regard to the content model for general task |
10/18/2011: Doc fix |
13095 |
Anderson |
In the classification domain, the topicSubjectTable (specialized from reltable) has a required title, but no explanation of why it is required and it is missing from the example. Suggest that the title be made optional; if TC agrees, I'm not sure if this should be a 1.3 item or a 1.2 errata item. The title is required in both the language spec topic, and in the DTD / XSD: |
10/25/2011: Yes, treat as bug fix |
n/a |
Kimber |
Conceptual Refinement for DITA 1.3: Navigation Tree |
Discussed at TC March 6, 2012, approve as doc clarification |
n/a |
Kimber |
Clarify that hasInstance semantic passes down to children, using interpretation #3 in the following email: http://lists.oasis-open.org/archives/dita/201203/msg00014.html |
Discussed at TC March 6, 2012 |
n/a |
Kimber |
Clarify that hasRelated can use @keyref: http://lists.oasis-open.org/archives/dita/201203/msg00015.html |
Discussed at TC March 6, 2012 |
Finished proposals approved for DITA 1.3
Items in this section have passed through the complete approval process and will be part of DITA 1.3.
# |
Owners / Champions / Sub-committee |
Requirement, links to final proposal, any amendments, or notes |
Initial acceptance |
Proposal Approved |
Approved and ready for 1.3 |