Next in thread →
Next in month →
Re: Fw: [dita] Proposal for <title> element in <topicref>
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.
Don R. Day
DITA and XML Consultant, Learning by Wrote
Co-Chair, OASIS
DITA Technical Committee
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
On 3/27/2012 10:54 AM, Michael Priestley wrote:
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
http://dita.xml.org/blog/25
----- Forwarded
by Michael
Priestley/Toronto/IBM on 03/27/2012 11:53 AM -----
From:
Eliot Kimber
<>
To:
Rob Hanna
<>,
Michael Priestley/Toronto/IBM@IBMCA, dita
<>,
Date:
03/27/2012 10:16 AM
Subject:
Re: [dita] Proposal
for <title> element in <topicref>
Per the brief discussion we had on the phone
last
week, when I asked a
similar question, the response was that the behavior would be
as for
navtitle and @locktitle, namely that the topicref's
<title> would
replace
the topic's title IFF @locktitle is yes, otherwise it would be
ignored.
I would expect the <title> to contribute to navigation
only if @locktitle
is
yes and there is no explicit navtitle on the topicref or on
the topic.
That is, even with @locktitle, a topic's explicit navtitle
still takes
precedence over a topicref's <title> when the topicref
has no separate
navtitle.
That is, I think, consistent with the general principle that
navtitle
overrides title for navigation and the presumption that if the
topic author
put in a navtitle they did so for a good reason.
Cheers,
E.
On 3/27/12 8:59 AM, "Rob Hanna"
<>
wrote:
> How do you envision the <title> element rendered in
the output?
Will it be
> used solely for navigation or will it replace the topic
title as well?
If it
> is solely for navigation, should we create a navtitle
element instead?
>
>
>
> 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
> <mailto:>
| www.innovatia.net
> <http://www.innovatia.net/>
| Follow us on Twitter
> <http://www.twitter.com/InnovatiaInc>
>
> Notice of Confidentiality: This e-mail message, including
any attachments,
is
> confidential and may be privileged. It is intended only
for the person(s)
> named above and any unauthorized distribution or
disclosure is prohibited.
If
> you have received this e-mail in error, please notify us
and permanently
> delete this email and any attachments from your system.
>
>
> From:
[] on behalf
of
> Michael Priestley []
> Sent: March 27, 2012 9:38 AM
> To: dita
> Subject: [dita] Proposal for <title> element in
<topicref>
>
> Problem:
> <topicref> has a number of ways to express title
information,
but currently
> 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
translation workflows
that
> need to put additional attributes on translatable content
elements
> navtitle, linktext, searchtitle are elements,
but all bound to
> specific outputs; in addition, they are all stored inside
<topicmeta>,
making
> them less accessible to authors, and more parallel to
<topic>'s
title
> alternatives, which are inside the prolog
>
> Proposal:
> Add a <title> element as the first, optional child
of <topicref>
to be
> parallel to <topic>; allowing easy access to a
title element
without adding a
> <topicmeta> container, and allowing a generic title
to be stored
without
> associating it with a particular output deliverable.
>
> Potential second proposal:
> It might also be useful to add a repeatable
<titlealt> element
inside both
> map's topicmeta and topic's <titlealts> element;
this would
provide the basis
> for creating output-specific alternate titles.
Unfortunately we couldn't
> easily change the existing alternate titles to be
specializations
of this base
> element, but it could be the basis for any new
specializations. For
example
> someone could specialize to create a <print-title>,
<mobile-title>,
> <audible-title>, etc. - whatever they find they
need.
>
> Michael Priestley, Senior Technical Staff Member (STSM)
> Lead IBM DITA Architect
>
> http://dita.xml.org/blog/25
<http://dita.xml.org/blog/25>
--
Eliot Kimber
Senior Solutions Architect, RSI Content Solutions
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.rsicms.com
www.rsuitecms.com
Next in thread →
Next in month →