OASIS Darwin Information Typing Architecture (DITA) TC

 View Only

  • 1.  Implications of navtitle on a mapref

    Posted 10-25-2012 15:35
    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/


  • 2.  RE: [dita] Implications of navtitle on a mapref

    Posted 10-25-2012 18:39
    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


  • 3.  Re: [dita] Implications of navtitle on a mapref

    Posted 10-25-2012 18:51
    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


  • 4.  Re: [dita] Implications of navtitle on a mapref

    Posted 10-25-2012 20:04
    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


  • 5.  Re: [dita] Implications of navtitle on a mapref

    Posted 10-25-2012 20:08
    The problem with the current spec language is that it doesn't tell you *when* a navigation title does not make sense. I can't think of any justification for thinking that topicrefs within a mapref would have any effect on topicrefs in the referenced map, so that seems like a very odd expectation. I think navtitles on maprefs is a case we should clarify in the spec, probably in the text of the <navtitle> element. It sounds like there is consensus that the navtitle has no effect on the navigation tree (is ignored just as titles of sub maps are ignored). Cheers, E. On 10/25/12 3:02 PM, "Robert D Anderson" <robander@us.ibm.com> wrote: > 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


Related Content