Re: [dita] Implications of navtitle on a mapref

[Robert D Anderson <robander@us.ibm.com>]

I would also assume #1 for the navtitle on a reference to a map. I think
the closest the spec comes to addressing this is a general comment in the
definition of <navtitle> --

"Because the navtitle element is available within topicmeta, and topicmeta
is used in many different contexts, it is possible that navtitle can be
specified in contexts where a navigation title does not make sense (for
example, on the topicgroup element). In those situations, the navtitle
element has no defined purpose. "

As to topicref children of references to other maps, I've always treated
those as if they have no defined purpose, and generated a warning that they
are ignored, partly due to the lack of definition for how they would be
used. I've seen some use cases where specialized topicref elements are used
to provide metadata, and the users expected that metadata to apply to the
nested map, but I was surprised by that expectation and I don't have any
processing that supports it. I think that's the only time my own users have
ever raised the issue of topicref inside a reference to a map.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)

<dita@lists.oasis-open.org> wrote on 10/25/2012 14:51:13:

> From: Eliot Kimber <ekimber@rsicms.com>
> To: dita <dita@lists.oasis-open.org>
> Date: 10/25/2012 14:52
> Subject: Re: [dita] Implications of navtitle on a mapref
> Sent by: <dita@lists.oasis-open.org>
>
> I agree that I would expect the answer to be #1.
>
> For topicrefs inside maprefs, it would make sense that the nested
topicrefs
> occur in the resulting navigation tree as siblings to the topicrefs in
the
> referenced map. The only other rule I can think of would be something
like:
>
> 1. IF the referenced map has exactly one normal-role topicref child
> (including topicgroups) THEN treat the nested topicrefs in the mapref as
> trailing children of that topicref.
> 2. IF the referenced map has no normal-role topicref children or more
than
> one THEN treat the map as though all of its child topicrefs were
contained
> in a single topicgroup element and apply rule (1).
>
> This rule would allow you to effectively add children to the root
resource
> referenced by the submap, which is probably what you would want from
nested
> topicrefs in a mapref but would avoid adding them as children of what
> happens to be first of several child normal-role topicrefs, which is
> probably not what you want.
>
> If you want full control over imposition of topicrefs onto referenced
maps
> you can always use anchors or conref push.
>
> Cheers,
>
> E.
>
>
> On 10/25/12 1:39 PM, "Chris Nitchie" <chris.nitchie@oberontech.com>
wrote:
>
> > I don't have a definitive answer, but I've always assumed #1.
> >
> > There's a similar vagueness in the spec for what happens to topicrefs
inside
> > maprefs.
> >
> > Chris
> >
> > -----Original Message-----
> > From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org]On
Behalf
> > Of Eliot Kimber
> > Sent: Thursday, October 25, 2012 11:35 AM
> > To: dita
> > Subject: [dita] Implications of navtitle on a mapref
> >
> > This question came up in the discussion of the new learningGroupMapRef
and
> > learnhingObjectMapRef elements:
> >
> > When a mapref has a navigation title, what is the processing
implication? I
> > see two options:
> >
> > 1. Like titles of submaps, it's ignored for the purpose of defining the
> > navigation title hierarchy.
> >
> > 2. It applies to the first normal-role topicref descendant of the
referenced
> > map.
> >
> > I couldn't find anything in the language reference that answers this
> > question.
> >
> > Do we know the answer to this question?
> >
> > Cheers,
> >
> > E.
> >
> >
> > --
> > Eliot Kimber
> > Senior Solutions Architect, RSI Content Solutions "Bringing Strategy,
> > Content, and Technology Together"
> > Main: 512.554.9368
> > www.rsicms.com
> > www.rsuitecms.com
> > Book: DITA For Practitioners, from XML Press,
> > http://xmlpress.net/publications/dita/practitioners-1/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: dita-help@lists.oasis-open.org
> >
> >
>
> --
> Eliot Kimber
> Senior Solutions Architect, RSI Content Solutions
> "Bringing Strategy, Content, and Technology Together"
> Main: 512.554.9368
> www.rsicms.com
> www.rsuitecms.com
> Book: DITA For Practitioners, from XML Press,
> http://xmlpress.net/publications/dita/practitioners-1/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: dita-help@lists.oasis-open.org
>