Items Approved for DITA 1.3

This page contains DITA 1.3 work items. These items either are DITA 1.2 bug fixes or DITA 1.3 proposals that have completed the approval process. [Return to the master DITA 1.3 Wiki page]

Bug fixes

Items in this section are minor items that passed stage 1; the TC decided that they did not need a formal proposal. 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?
NOTE: may overlap with 12007
7/26: Simplify to "set processing-role to resource-only on relationship tables" and then treat this as a fix. This clearly represents the original intent for relationship tables, so there is no change in meaning for any part of the specification.

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: For completeness, should add both. These are universal attributes treated elsewhere as a group; no reason to exclude either.

8/2/2011: Treat as bug fix.

13053

Yeo

Use relationship tables to create topic-to-topic links in the DITA Specification document. This would greatly improve the usability of the spec. We have things like, "For a detailed description of the chunk attribute and its usage see the section on Chunking in the DITA Architectural Specification" with neither an inline hyperlink nor a See Also link taking you to the section on chunking in the DITA Architectural Specification. Good golly, we can do better :)
9/20: Work on this took place in DITA 1.2 but was nowhere near complete. How to best address for DITA 1.3? Will create a proposal with an official set of guidelines for the future, plus items that could be updated for 1.3. Kris to take over from Su-Laine.

9/20/2011: Yes

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: Treat as bug fix / oversight.

9/20/2011: Treat as bug fix

13055

Yeo

Consider making <reqconds> and <reqpers> elements derive from UL, not OL.
9/20: Robert remembers this being discussed at 1.2, with no response from the machinery group. Eliot agrees that <ol> is not appropriate. Robert points out no backwards compatibility issues; styling may change from numbers to bullets, but that sounds correct. Kris to notify the machinery SC and we will treat as bug fix.

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: Update would add a note to the id-atts topic stating that elements which use this group will use an @id type NMTOKEN, but that other elements may use type ID.

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: Scope this specifically to allow msgph and msgnum within msgblock, which fits language already in the spec. Treat as bug fix (update DTD / Schema to match language). Will not add <ph> into the msgblock model.

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/4: Su-Laine to investigate and come back with a pointer to the wording that actually needs to change or prohibits the desired behavior.

10/18: Follow-up email: http://lists.oasis-open.org/archives/dita/201110/msg00009.html
As suggested in the email, TC agrees to treat this as a documentation item (add to change log as an old rule that no longer applies).

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: Treat as doc item for these two elements: @locktitle does not apply, and other attributes only apply for cascading (such as @format and @scope). Will not do a broader analysis of other specialized elements unless somebody takes on a proposal.

10/18/2011: Treat as doc fix / update.

13083

Eberlein

Correct spec in regard to the content model for general task
See http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201106/msg00014.html

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:
http://docs.oasis-open.org/dita/v1.2/os/spec/langref/topicSubjectTable.html

10/25/2011: Yes, treat as bug fix

n/a

Kimber

Conceptual Refinement for DITA 1.3: Navigation Tree
http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201202/msg00028.html (Eliot Kimber, 5 Feb 2012)
http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201202/msg00029.html (Michael Priestly, 5 Feb 2012)
http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201202/msg00030.html (Eliot Kimber, 5 February 2012)
http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201202/msg00053.html (Eliot Kimber, 19 Feb 2012)

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

n/a

TC

Clarify that data can use @keyref; clarify that specializers may give their own semantic to href/keyref on <data>, though the addressing syntax may not change.

Discussed at TC May 14, 2013

n/a

Kimber/TC

TechCom map should include classification domain (ensure Robert understood the outcome properly for this item, based on minutes that come out this week)

Discussed at TC May 14, 2013

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

Stage 1 approval

Stage 2 approval

Stage 3 approval

13008

Anderson
Reviewer 1: Don Day
Reviewer 2: Stan Doherty
Reviewer 3: Kris Eberlein

Consider adding @appid as a new optional CDATA attribute on <resourceid> and making the existing @id optional.

30 December 2011: Phase 2 proposal submitted: HTML, DITA

3 January 2012: Proposal discussed at TC meeting

10 January 2012: Phase 2 proposal approved

20 August 2012: Stage 3 proposal sent to reviewers

28 August 2012: Responded to comments from Stan and Kris. Proposal uploaded and ready for discussion next week. HTML, DITA

28 June 2011

10 January 2012

11 September 2012

13078

Nitchie
Reviewer 1: David Helfinstine
Reviewer 2: Nancy Harrison

Consider adding the @rotate attribute from the CALS table model to the version of the OASIS Exchange table model used in DITA topics.
10/11: @rotate applies only to entry element. Will also try to pick up @orient at the table level. Will require careful wording related to style (landscape table in middle of 2-col, or in HTML, etc).

Jan 22 2013: Approved final Stage 3 proposal, add to DITA 1.3 approved list

10/11/2011: Yes

07/10/2012

Jan 22 2013

DITA_1.3_Proposals (last edited 2013-05-14 15:58:20 by robander)