Eliot, this seems to add unnecessary expectations for live content.
In a DITA WCMS (is that what we'll call this single database,
wiki-like architecture?), you want to avoid lookups whenever
possible, typically only when one of the topicrefs is missing a
navtitle. The ToC author (whether aware or not that they are
actually manipulating the data model of a DITA map) would be
understandably astonished if their directly-authored change didn't
"take". In our discussion today about HTML-based authoring
expectations, the principles that I caught for lightweight DITA
authoring were along the lines of "make the writing intent as
obvious as possible," to which I'd now also add "render as directly
as possible" as a corollary.|
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
On 3/27/2012 10:54 AM, Michael Priestley wrote:
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
Priestley/Toronto/IBM on 03/27/2012 11:53 AM -----
Michael Priestley/Toronto/IBM@IBMCA, dita
03/27/2012 10:16 AM
Re: [dita] Proposal
for <title> element in <topicref>
Per the brief discussion we had on the phone
week, when I asked a
similar question, the response was that the behavior would be
navtitle and @locktitle, namely that the topicref's
the topic's title IFF @locktitle is yes, otherwise it would be
I would expect the <title> to contribute to navigation
only if @locktitle
yes and there is no explicit navtitle on the topicref or on
That is, even with @locktitle, a topic's explicit navtitle
precedence over a topicref's <title> when the topicref
has no separate
That is, I think, consistent with the general principle that
overrides title for navigation and the presumption that if the
put in a navtitle they did so for a good reason.
On 3/27/12 8:59 AM, "Rob Hanna"
> How do you envision the <title> element rendered in
Will it be
> used solely for navigation or will it replace the topic
title as well?
> is solely for navigation, should we create a navtitle
> Rob Hanna, CIP
> Senior Information Architect, Innovatia Inc.
> STC Associate Fellow
> Certified Information Professional - AIIM
> Tel: +1 (506) 674-5660 | Fax: +1 (289) 997-3263 | Cell:
+1 (416) 723-4183
> email@example.com <mailto:firstname.lastname@example.org>
| Follow us on Twitter
> Notice of Confidentiality: This e-mail message, including
> confidential and may be privileged. It is intended only
for the person(s)
> named above and any unauthorized distribution or
disclosure is prohibited.
> you have received this e-mail in error, please notify us
> delete this email and any attachments from your system.
> From: email@example.com
[firstname.lastname@example.org] on behalf
> Michael Priestley [email@example.com]
> Sent: March 27, 2012 9:38 AM
> To: dita
> Subject: [dita] Proposal for <title> element in
> <topicref> has a number of ways to express title
> all are bound to specific output expressions:
> @navtitle is bound to navigation output;
in addition it is an
> attribute, which makes it hard to process through
> need to put additional attributes on translatable content
> navtitle, linktext, searchtitle are elements,
but all bound to
> specific outputs; in addition, they are all stored inside
> them less accessible to authors, and more parallel to
> alternatives, which are inside the prolog
> Add a <title> element as the first, optional child
> parallel to <topic>; allowing easy access to a
without adding a
> <topicmeta> container, and allowing a generic title
to be stored
> associating it with a particular output deliverable.
> Potential second proposal:
> It might also be useful to add a repeatable
> map's topicmeta and topic's <titlealts> element;
provide the basis
> for creating output-specific alternate titles.
Unfortunately we couldn't
> easily change the existing alternate titles to be
of this base
> element, but it could be the basis for any new
> someone could specialize to create a <print-title>,
> <audible-title>, etc. - whatever they find they
> Michael Priestley, Senior Technical Staff Member (STSM)
> Lead IBM DITA Architect
Senior Solutions Architect, RSI Content Solutions
"Bringing Strategy, Content, and Technology Together"