This Wiki page is designed to collect comments on the second review of the DITA 1.2 specification, 21 September - 3 October 2009. This review is being conducted by members of the OASIS DITA Technical Committee.

Previous | Next | Home page for the second review

Important: Reviewers, be sure to preface comments with your name and the date, for example, [Eberlein, 18 September 2009]

[WEK, 5 Dec 2009] The addressing-related attributes and other addressing and linking information in the lang ref has been reorganized and editorially refined as part of the general linking and addressing reorg. All relevant comments here were implemented as appropriate as part of the reorganization activity, unless otherwise indicated.

Commonly referenced attributes

[WEK, 2 Nov 2009] This section is organized around the names of the literal parameter entities used to organize various attribute declarations for the convenience of DTD-based vocabulary module implementors. However, those parameter entities are necessarily relevant (%rel-atts, which is deprecated). Probably too late to change for 1.2, but for 1.3 we should consider reorganizing this section around logical groupings of attributes named in the way Kris has generally suggested in her comments, avoiding reference to the literal parameter entities. If it's necessary to document set of parameter entities somewhere (I don't think it is), that should be in a separate section that deals with vocabulary module implementation. What's important is the semantics of the attributes, not how their declarations are organized syntactically.

[RDAnderson, November 4 2009] During the initial language spec review, somebody commented that it was an error to include any entity names in the spec (particularly in the attribute tables). I brought this up at a TC meeting, and the consensus was to leave them as is at this point rather than creating new names. So, I'm inclined to leave them as-is for 1.2, but I'm happy to address it again in 1.3.

display-atts attribute group

[Eberlein, 21 September 2009] Could we simply call this the "display attributes group"?

[RDAnderson, November 4 2009] Leaving as-is, per comments above


[Eberlein, 22 September 2009] The statement in the row for the @frame attribute is missing a word: "Some DITA processors or [xxxx] may not be able to support all values.

[RDAnderson, November 4 2009] Fixed, to match similar statements elsewhere


[Eberlein, 22 September 2009] In the Description cell of the @expanse attribute, use a <dl> element to format the text; make it parallel to the content in the row above

[RDAnderson, November 4 2009] Done


[WEK, 2 Nov 2009]] Description of @expanse says '"page" places the element on the left page margin'. Should not refer to "left" and "right" but "inside" and "outside" to accommodate right-to-left presentations (e.g., as is done in the XSL-FO spec.

[RDAnderson, November 4 2009] I looked at the XSL-FO spec, and it seems using inside / outside will require a lot of additional explanation - for example, English documents would be on the outside for left-page presentation and inside for right-page presentation. One of the many explanations of inside in that spec is "If the page binding edge is on the start-edge, the alignment will be start. If the binding is the end-edge, the alignment will be end. If neither, use start alignment." In an effort to simplify, I've updated the current definition of "page" to read "Places the element on the left page margin for left-to-right presentation, or right page margin for right-to-left presentation."

global-atts attribute group

[Eberlein, 21 September 2009] Could we simply call this the "debugging attributes group"?

[RDAnderson, November 4 2009] Leaving as-is, per comments above


[Eberlein, 22 September] Change "filename" to "file name"

[RDAnderson, November 4 2009] Done

univ-atts attribute group

[Eberlein, 21 September 2009] Could we simply call this the "universal attributes group"?

[RDAnderson, November 4 2009] Leaving as-is, per comments above


[Eberlein, 22 September 2009] In the Description cell of the @conaction attribute, change "another topic" to "a topic"

[RDAnderson, November 4 2009] Changed to "a new location", as it can also push content into a location within a map.

id-atts attribute group

[Eberlein, 21 September 2009] Could we simply call this the "id attributes group"?

[RDAnderson, November 4 2009] Leaving as-is, per comments above


[Eberlein, 21 September 2009] I thought the example a little confusing, since content suggests (main paragraph, dull paragraph) suggests that some sort of filtering would be happening. Using the @id attribute for conreffing seemed clear ...

[RDAnderson, November 4 2009] Removed example - it's unhelpful, and better (more complete) conref examples are given in the more detailed conref topics.


[WEK, 2 Nov 2009] For @id: Should probably have a crossref to general discussion of ID scoping in the arch spec.

[RDAnderson, November 4 2009] Added xref


[WEK, 2 Nov 2009] For @conkeyref, change "in place of a file name" to "instead of a URI".

[RDAnderson, November 4 2009] Done

select-atts attribute group

[Eberlein, 21 September 2009] Could we simply call this the "metadata attributes group"?

[RDAnderson, November 4 2009] Leaving as-is, per comments above


[WEK, 2 Nov 2009] @product: "Contains the name of the product to which the topic applies." C/the topic/the element/

[RDAnderson, November 4 2009] Done


[WEK, 2 Nov 2009] @otherprops: Probably useful to add a note that an alternative to @otherprops is to specialize from @props.

[RDAnderson, November 4 2009] Done


[WEK, 2 Nov 2009] @importance: Would be useful to have some presentation expectation or examples here. For example, is this intended to be used for flagging? It appears from the text in the DitaVal section that @importance is not recognized by the <prop> element. Should it be?

[RDAnderson, November 4 2009] Added the following comment: "This attribute is not used for DITAVAL based filtering or flagging; applications may (but need not) use the importance value to highlight elements."


[WEK, 2 Nov 2009] @status: Change to "The modification status of the element" (added "modification"). Unqualified "status" is too general, even though the enumerated value list makes the intent clear. Note that ideally we would add the value "reverted" to the list, although I'm sure it's too late for that in 1.2.

[RDAnderson, November 4 2009] Done, added "modification"


[Eberlein, 21 September 2009] In the <shortdesc> element, change "Conditional Processing" to "conditional processing"

[RDAnderson, November 4 2009] Done


[Eberlein, 21 September 2009]

[RDAnderson, November 4 2009] Deleted the sentence. I've added a related link to conditional processing information. I can no longer find a topic dedicated to attribute specialization (!!), so I have not linked to that. It may be more appropriate to have this as a reltable link, but I'm not sure which maps should contain that, so for now it's in the topic.

[WEK, 5 Dec 2009] Added related links to the attribute specialization and attribute domain code requirements topics.


Paul [2009-09-23]: What Kris says also goes for the reference to the arch spec in the props and base attribute descriptions

[RDAnderson, November 4 2009] Fixed, the descriptions now link.


[Eberlein, 23 September 2009] In the Description cells for the @platform, @product, @audience, and @otherprops, change "inherit" to "cascade."

[RDAnderson, November 4 2009] Done


[Eberlein, 23 2009] I'm guessing that the multiple examples are contained in <lines> element. Can you use something else that might produce white space between the elements? On first glance, one might think that this was supposed to be a single code sample.

[RDAnderson, November 4 2009] It used <codeblock>. I've added spaces between each line.


[JTH: 1 October 2009. In "otherprops" -- Why are we still explaining the labeled group when it was deprecated in 1.1? Please spell labeled without the double ll. Preferred US spelling.

Here's the paragraph: For example, a simple otherprops value list: <codeblock otherprops="java cpp"> The attribute can also take labelled groups of values, but this syntax is deprecated in DITA 1.1 in favor of attribute specialization. The labelled group syntax is similar to the generalized attribute syntax and may cause confusion for processors. A labelled group consists of a string value followed by an open parenthesis followed by one or more space-delimited values followed by a close parenthesis. The simple format is sufficient when an information set requires only one additional metadata axis, in addition to the base metadata attributes of product, platform, and audience. The full format is similar to attribute specialization in that it allows two or more additional metadata axes. For example, a complex otherprops value list: <codeblock otherprops="proglang(java cpp) commentformat(javadoc html)"> ]

[RDAnderson, November 4 2009] It appears that another editor has removed the section about the deprecated syntax - I do not see it in the "otherprops" description at this point. It appears "labelled" has also been removed.

localization-atts attribute group

[Eberlein, 21 September 2009] Could we simply call this the "localization attributes group"?

[RDAnderson, November 4 2009] Leaving as-is, per comments above


[JeffO, 06 October 2009] I'd suggest this wording:

[RDAnderson, November 4 2009] Resolved with the next comment...


Paul [2009-10-02]: Under the xml:lang attribute, the draft says:

This sentence is wrong and should be deleted.

First, when no xml:lang is supplied on a given element, it inherits from its ancestors. This behavior is defined in the XML spec and cannot be overridden.

Furthermore, when no xml:lang is supplied, that is the same as saying xml:lang="" which is defined in the XML spec as indicating that no language information is available. The XML spec says:

It is wrong (to say nothing of anglo-centric) to say that "no language" should default to English. There are things such as computer code and file names that are not associated with any given natural language, and it must be possible to indicate this by omitting (or resetting to null) xml:lang.

Later is the same description, the draft says:

This is wrong, as has been noted and corrected elsewhere in the spec (the arch spec, DITA processing, translation, the xml:lang attribute). It does not mention the null value, and it doesn't refer to the XML spec which is the authoritative one for defining xml:lang. This sentence should be changed to match that in the arch spec to:

[RDAnderson, November 4 2009] Removed the comment about English, and the comment about "es" causing the note to print the text "Nota" instead of the default "Note". Also updated the reference to use the suggested wording. The complete description now reads: "Specifies the language of the element content. The xml:lang attribute and its values are described in the XML Recommendation at http://www.w3.org/TR/REC-xml/#sec-lang-tag.


Paul [2009-09-23]: Under the dir attribute, the draft says:

This should be an xref, and the arch spec shouldn't have best practices--that should be in another document. So we should say something like:

Also the initial para of this page reference the arch spec and mentions best practices. That should be amended too.

[RDAnderson, November 4 2009] Done, changed the dir attribute to use xref, and replaced the "more information about translation" paragraph with a related link to the translation topic.


[Eberlein, 23 September 2009] Paul is suggesting an <xref>. In general, how do we want to handle linkages between the arch spec and lang ref? Between the lang ref and the arch spec? We've got a number of possibilities; I think we should develop a consistent approach, if possible:

[RDAnderson, November 4 2009] In general, I'd suggest the reltable link. This doesn't work well for links within the attribute table though, since those are reused in unknown locations via conref, and it would not make sense to manage those as related links. When topics are related to other topics, I've used <related-links>, but in general I think reltable links are wiser - I held off mostly because I'm not sure what maps are impacted.

relational-atts attribute group

[Eberlein, 21 September 2009] Could we simply call this the "navigation attributes group"?

[RDAnderson, November 4 2009] Leaving as-is, per comments above


[WEK, 2 Nov 2009] Intro para, c/These attributes occur only on elements that represent relationships between topics./These attributes occur only on elements that represent relationships among DITA elements or between DITA elements and non-DITA resources/. Used "among" for DITA elements because reltables can establish many-to-many relationships. Used "between" for DITA and non-DITA because DITA only enables binary relationships between DITA elements (topicref, link, xref) and non-DITA resources. Also, it looks like @role and @otherrole are only available on related-links and link, which makes this organization a little odd, since the implication is that these attributes are available on all linking elements (topicref, xref, link).

[RDAnderson, November 5 2009] Done

rel-atts attribute group

[Eberlein, 23 September 2009] Consider changing "The parameter is deprecated in DITA 1.2" to "Beginning with DITA 1.2, the parameter is deprecated." This might avoid needing to change the wording for DITA 1.3.

[RDAnderson, November 5 2009] Done

topicref-atts, topicref-atts-no-toc, and topicref-atts-without-format attribute groups

Paul [2009-09-23]: I don't understand the print attribute's printonly value. This needs to be explained better.

[RDAnderson, November 5 2009] Updated, based on reading the description here: http://docs.oasis-open.org/dita/v1.1/OS/archspec/transitionaltext.html -- the new wording is "Only include the topic when rendering the DITA content in a print-oriented context; the topic should not be included in other contexts, such as when rendering as HTML." If we want something better, I'm open to suggestions...


[WEK, 2 Nov 2009] @type. Change /Describes the target of a cross-reference./Describes the target of a reference./ Since @type is used for topicref as well as xref.

[RDAnderson, November 5 2009] Done


[WEK, 2 Nov 2009] @locktitle. Need to generalize reference to the navigation title, since it can come from @navtitle (deprecated) or navtitle subelement.

[RDAnderson, November 5 2009] Done


[WEK, 2 Nov 2009] @format. Change /cross referenced/referenced/

[RDAnderson, November 5 2009] Done


[WEK, 2 Nov 2009] @linking. Change /but it specified/but is specified/ (and elsewhere this typo appears to have been copied, e.g., @search).

[RDAnderson, November 5 2009] Done


[WEK, 2 Nov 2009] @toc. Table of contents should be abbreviated "TOC" or "ToC" (Kris?).

[RDAnderson, November 5 2009] Not sure about this one - you mean we should not include the spelled out version?


[WEK, 2 Nov 2009] @print. Change "in a portable document format (PDF) file" to "in a print-specific rendition, such as PDF" and update remaining text as well. I think "PDF" is sufficiently ubiquitous that it's not necessary to expand it.

[RDAnderson, November 5 2009] Done


[WEK, 2 Nov 2009] @chunk. The @chunk attribute is conspicuous for not being documented in this part of the language spec. It should be, I think. In particular, the subtopic "Usage of the chunk attribute" currently under the "Chunking" topic in the arch spec should be moved to the language spec, since it's defining the details of the @chunk attribute.

[RDAnderson, November 5 2009] Agreed, though I'm not sure where to link at this point - is some reorganization happening that will result in a moved file?


[JeffO, 06 October 2009] The processor supplied default value for @print is 'yes". We should say that.

[RDAnderson, November 5 2009] Done


Paul [2009-09-23]: The reference to the arch spec under the chunk attribute should be an xref.

[RDAnderson, November 5 2009] Agreed, but not done yet, pending reorganization of chunk information between arch spec and lang spec


[Eberlein, 21 September 2009] Could we simply call this the "map attributes group"? Or "topicref attributes group"? Do we need all three attribute groups? If yes, why? (It just seems to add layers of complexity ...)

[RDAnderson, November 5 2009] Leaving as is for now, as decribed at the top. One problem here is that these are three distinct groups, and are referenced as such from different attribute tables. Previously there was one topic for each group, and the elements linked directly to the correct group, but that was deemed too repetitive in a previous review.


[Eberlein, 23 September 2009] In the Description cell for the @collection-type attribute, consider using a <dl> to make it easier to read the explanations of the values that the attribute can take.

[RDAnderson, November 5 2009] Done


[Eberlein, 23 September 2009] Regarding the @processing-role attribute, doesn't the default value depend on the element type? For example, I assume that the default value for <keyfe> is "resource-only."

[RDAnderson, November 5 2009] The default value is "normal" for any element using these topicref-atts groups. The keydef element should have (and now has) its own definition, which gives a default of "resource-only".


[Eberlein, 23 September 2009] In the rows for @processing-role, @linking, @toc, @print, and @search, change "inherit" to "cascade"

[RDAnderson, November 5 2009] Done

Other common DITA attributes

[WEK, 2 Nov 2009] @class. Need an xref to the general discussion of the class attribute in the Arch Spec.

[RDAnderson, November 5 2009] Done


[WEK, 2 Nov 2009] @xml:space. C/line-end characters/white space, including line-end characters,/

[RDAnderson, November 5 2009] Done

Complex attribute definitions

[Eberlein, 1 October 2009] I'd like to see this content collection at the same level as "Commonly-referenced attributes." Can we add a container topic so that they would become peers? For example:

Attributes ---Commonly referenced attributes ---Complex attribute definitions

As information architect, I'd like to see these critical topics bumped up a level in the hierarchy.

[RDAnderson, 9 December 2009] Done - though I'll point out that adding the "Attributes" topic actually bumps one group down (the common groups) rather than bumping the other topics up.

The href attribute

[Eberlein, 1 October 2009] Eliot Kimber and I have recently had an e-mail exchange about whether the DITA specification should refer to "DITA files":

There are several references to "DITA files" in this topic.

[RDAnderson, 8 December 2009] Fixed - "file" now only appears in the examples, such as href="file.dita"


[Eberlein, 1 October 2009] Change all instances of "URI-reference" to "URI reference"

[RDAnderson, 8 December 2009] Fixed

Using keys and keyref

[WEK, 2 Nov 2009] Suggest including use of the term "key space" in the discussion of the key definition scoping rules (bullet 8 starting "Key definitions are part of..."). E.g., 'Key definitions are part of a global key namespace ("key space") that is defined by a particular map hierarchy.' (added '("key space")')

[RDAnderson, 8 December 2009] The "using keys and keyref" topic has disappeared from the map. I assume that this comment was addressed in Eliot's re-org of key related content.

The keys attribute

[WEK, 2 Nov 2009] Redundant specification of the lexical rules for keys. Either remove from general discussion under "Using keys and keyref" or remove from here. Suggest removing from general discussion, otherwise topic doesn't really serve any purpose and I think it's important to have each attribute represented by its own topic.

[RDAnderson, 8 December 2009] I think this is no longer redundant, with the removal of the "using keys and keyref" topic.

The keyref attribute

[WEK, 2 Nov 2009] c/The keyref attribute provides an indirect reference to/The keyref attribute provides an indirect, late-bound reference to/. Added "late-bound", since it is the late binding, not just the indirection, that provides the power of keyref. Indirection without late binding would not satisfy the requirements the key mechanism satisfies.

[RDAnderson, 8 December 2009] OK, added late-bound


[WEK, 2 Nov 2009] Redundant definition of the lexical rules for keyrefs. Remove from general discussion (per my comment on @keys).

[RDAnderson, 8 December 2009] Assume that this is handled - the parent topic no longer exists.


[WEK, 2 Nov 2009] "Overview of what keyref may do": The language is not technically correct in that keyref does not define a "replacement" for an href specified on the same element, but simply takes precedence over any href, where the href is used as a fallback. But this is already covered in the "Using keys and keyref" section, so I'm not sure this topic is even necessary. Likewise, keyref does not "convert" an element into a link but simply makes it be a link. That is, the effect of @keyref is to establish the semantic of the element, so using terms that imply transformation are inappropriate. That is, a term element with keyref specified is a link, by its essential nature. A term element without keyref is not a link, by its essential nature. Finally, a keyref does not define text to be placed in the referencing element. It is the key definition that provides the effective value of the element's content when the element has no directly-specified content.

[RDAnderson, 8 December 2009] The overview was removed from this topic - I assume that this item is complete, per Eliot's reorg of keyref related topics


[WEK, 2 Nov 2009] Topic "Resolving keyref": This topic is probably best moved to the Linking and addressing" topic in the architectural spec, but in any case it needs to be rewritten in terms of the "effective values" of the resource addressed by the key, not in terms of literal processing. In addition, the "specifies href/doesn't specify href" is not sufficient because a key-defining topicref may address its resource indirectly via a key reference, so the distinction is really "addresses a resource/doesn't address a resource". Suggest this rewording:

{Replace current first bullet with these paragraphs: }

A key definition may address a DITA or non-DITA resource directly (via @href) or indirectly (via @keyref). It may also contain subelements that can provide the effective values of elements that specify @keyref, as deterimed by the element type of the element making the key reference. The resource ultimately addressed by a key definition becomes the target of any navigable links that refer to the key. This includes both dedicated linking elements (topicref, link, xref) and elements that become links when they specify a key reference to a resource-addressing key definition (term, keyword, etc.). The subelements within the topicmeta subelement of the key definition, if any, provide the effective text of elements that specify key references when those elements do not have directly-specified text.

A key definition that addresses a resource is said to be "bound" to the resource.

A key definition that does not address a resource and has no subelements applicable to a given reference to the key is not an error. In that case, the key reference is equivalent to no key reference having been specified. For elements that also specify an @href attribute, the normal fallback rules apply. For elements that do not specify an @href, the effect is the same as if @keyref had not been specified.

Within topics, elements that reference keys that are bound to resources are navigable links to those resources unless the key definition specifies "none" for its @linking attribute.

Within topics, elements that reference keys and that do not have directly-specified content use the text of any corresponding subelement within the key definition's topicmeta element. If the key definition does not have an applicable subelement, normal link text determination is applied as for xref elements. This processing is applied even if the topic definition specifies "none" for its @linking attribute. If no link text can be determined, the referencing element's effective content is empty.

It is an error for an element to reference a key that is not defined if the element does not also specify @href and the element has no directly-specified content. In this case processors MAY give an error message and MAY recover from the error by leaving the referencing element empty.

{Continue with existing content starting "Matching element content falls into one of two categories..."}

[RDAnderson, 8 December 2009] The indicated topic has been moved to the architectual spec as part of Eliot's reorg; I assume that this change was handled as part of that reorg.


[WEK, 2 Nov 2009] c/carry/specify/ for attributes: Elements specify attributes, they do not carry or contain them.

[RDAnderson, 8 December 2009] Handled as part of Eliot's reorg; "carry" no longer appears in this topic.

The conkeyref attribute

[WEK, 2 Nov 2009] c/Instead the key used within the conkeyref attribute replaces whatever high-level object is defined in the conrefend attribute./Instead, the resource addressed by the conkeyref attribute is used in place of the topic or map addressed by the conrefend attribute/

[RDAnderson, 8 December 2009] Eliot updated this topic significantly - the original wording was changed but does not match the suggested new wording. As both came from Eliot, I assume the latest content in the topic is correct.

The conref attribute

[Eberlein, 1 October 2009] Change "It allows reuse of DITA components from phrases to topics as well as maps and pieces of maps." --> "It allows reuse of DITA components: elements, topics, DITA maps, and pieces of maps."

[RDAnderson, 8 December 2009] I'm not sure why there is a distinction between elements and "pieces of maps" - both are elements. I've updated this to read "It allows reuse of DITA elements, including topic or map level elements."


[WEK, 2 Nov 2009] All the discussion in this section of specific syntax is redundant with the general linking and addressing syntax in the arch spec. It should be removed from here. Should simply point to the arch spec discussion. Also, in general, text like "This attribute is used to reference an ID" is not really correct because the attribute is not referencing an ID, it's referencing an element by ID. What's important is that you can reference an element, not the details of the addressing syntax (which may not be limited to ID-based references in a future version of DITA).

[RDAnderson, 8 December 2009] Removed the duplicated info (the three sections about syntax for topic, topic element, and map element reuse)


[Eberlein, 1 October 2009] In "Using conref to refer to a topic," avoid the references to files. Here is some possible rewording (changed text highlighted in bold

Target elsewhere in the same DITA resource: conref="#topicid" First topic in different DITA resource: conref="filename.dita" Specific topic in different DITA resource: conref="filename.dita#topicid"

[RDAnderson, 8 December 2009] Done - changed to "DITA document", per comments above (regarding XML's use of document in place of file). Also changed in a few more spots in the ... ahem ... file.

[RDAnderson, 11 December 2009] Most of those sections are now commented out, based on Eliot's previous comment.


[WEK, 2 Nov 2009] c/ During output processing, a lookup process will pull the contents of the first topic into the calling topic markup that has the conref attribute./During output processing, the referenced topics will be used in at the point of reference in the referencing topics./ NOTE: this example is important but perhaps too brief. My main objection to the text as written is to the phrase "pull the contents ... into the calling topic markup". That reflects a particular implementation approach that is not required by the spec. It is not the markup that is pulled but the element.

[RDAnderson, 9 December 2009] Updated


[Eberlein, 1 October 2009] In "Using conref to refer to an element within a topic":

[RDAnderson, 9 December 2009] For the first item - I'm uncertain about this one. The only common item is that the value must be a URI reference. When referring to a topic, it is only a URI reference or URI reference plus topic ID; in this section, it's described as the reference + #id + /elementid. The URI reference items is already specified ahead of that note. [Regardless, much of this information likely now duplicates information in the architectural spec and should be removed - I just need to figure out where to point.] For the second item - done.

[RDAnderson, 11 December 2009] The "Using conref to refer.." sections are now commented out. The full details of URI references are already specified in the URI Reference topic from the archspec, so the link (above the <note>) is sufficient.


[Eberlein, 1 October 2009] In "Using conref to refer to an element within a map", change "In different file" to "in different DITA map"

[RDAnderson, 9 December 2009] Changed to "in another DITA document" - the target does not have to be a map (you can pull a phrase from a DITA topic into a map).

Using the -dita-use-conref-target value

Paul [2009-09-23]: The reference to the arch spec at the bottom of this page should be an xref.

[RDAnderson, 9 December 2009] Done - replaced the paragraph with a link.


[Eberlein, 1 October 2009] I was not familiar with this attribute value. I had to read the topic several times before I understood what it was trying to say. Perhaps a more realistic example would help the reader? All I get from the current example is that you can use @navtitle set equal to -dita-use-conref-target in order to avoid getting a processing error because of an empty (required) attribute ... Maybe that's the point?

[RDAnderson, 9 December 2009] That's the primary purpose, yes - the attribute is required, so XML forces you to specify it, but you don't want to override the value you'd otherwise get from the referenced element. Using -dita-use-conref-target means ... use what is on the target of the conref (this was before the confusion came out about "target").

Ugh. Follow-up to that is - the topichead element no longer requires navtitle. The example is still valid, because the result is the same, but the text should not refer to this as a required attribute. I've added several clarifications of the purpose of the value, and reduced extra wording that isn't needed (go minimalism!), so I hope that the topic is clear now.

The conaction attribute

[Eberlein, 1 October 2009] Regarding the unordered list at the beginning of the topic, are these "restrictions" unique to conref push or do they apply to all conref operations? If the latter, the material might be better located in a general topic about conref.

[RDAnderson, 9 December 2009] It's similar to general conref restrictions, but opposite (when speaking of referencing / referenced elements). So, it's probably best to be specific here about which element in which location must be more specialized / etc. That is - conref may only reference the same or a more specialized element; conref push may only reference the same or a more general element.

The conrefend attribute

The type attribute

Next item added to this list by Robert Anderson, copied from email from Gershon / Seth Park

[Eberlein, 14 July 2009] Here is content of another draft comment from a DITA map topic, an exchange between Jeff Ogden and Michael Priestley: Comment from Jeff Ogden 2007/01/22: Is there a description of how conflicts are resolved? A conflict between the type attribute value on a topicref and the actual type of a DITA topic. A conflict between the type attribute on different topicrefs. The same question for other topicref attributes: format, scope, ....?

MP response: Conflict between type on topicref and type of target should result in a warning when detected - effectively if someone sets type explicitly on a local link, it's like putting an assertion in code - you're doing it so you can find out when you're wrong. That should be in the language spec if it's not. Conflicts between topicrefs are resolved through inheritance as above - not sure I'm getting the question right, but hoping we can address for 1.2.

[RDAnderson, 9 December 2009] It appears that this topic has been updated. It now includes the usual language added in 1.2 about "may, but need not" issue a message for conflicts.


[Eberlein, 1 October 2009] Regarding "If not explicitly specified on an element, the type attribute inherits its value from ancestors" ...This is a situation where the value of the @type attribute cascades to the children elements. How can we rephrase this to use the cascading terminology?

[RDAnderson, 9 December 2009] Updated.


[WEK, 2 Nov 2009] Per action from July 14 2009 TC meeting for me to propose additional language for type attribute. Add after "If the type attribute is specified when referencing DITA content, it should match one of the values in the target's class attribute." new sentences: The @type value may be an unqualified local name (e.g. "fig") or a qualified name exactly as specified in the @class attribute (e.g., "mymodule/mytype"). Processors may ignore qualified names or may consider only the local name.

[RDAnderson, 9 December 2009] Added the language.


[RDAnderson, 4 Decmeber 2009] The description still shows caution1 and caution2 as new values for note/@type. These were removed from the <note> element, and should be removed here as well.

[RDAnderson, 4 December 2009] Updated.

The format attribute

[Eberlein, 1 October 2009] In the short description, change inherit to "cascade."

[RDAnderson, 9 December 2009] Done


[Eberlein, 1 October 2009] In the description of the format="ditamap," what does "It represents a referenced hierarchy at a position within referencing hierarchy, and a referenced relationship table included outside the referencing hierarchy" mean? The current phrasing is kind of opaque ...

[RDAnderson, 9 December 2009] Replaced the wording with: "It represents the referenced hierarchy at the current point in the referencing map. References to other maps may occur at any point in a map, but because relationship tables are only valid as children of a map, referenced relationship tables are treated as children of the referencing map."

The scope attribute

[Eberlein, 1 October 2009] Change "the value will inherit" --> "the value cascades"

[RDAnderson, 9 December 2009] Done

The role attribute

LangRefAttributes (last edited 2009-12-11 14:41:54 by robander)