RE: [dita] Map structure and possible new attribute for conref push and anchorref

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

I agree that using <topicref> to pull collections of conref targets into
the map invites user confusion. It would require clear instruction,
probably best practice to put them at the end of the map.

Su-Laine:
> I am not sure why we need to add a new <anchorref> element when it
seems to do the same thing as conref push.

How do we use conref= for the following use case and example from the
proposal? What element gets the conref=?

A writer has written a map to define the end-to-end procedure for
preparing a car for rental. The procedure has <anchor> elements at
appropriate extension points for model-specific tasks as part of the
procedure. Another writer has written a map to define the tasks specific
to maintaining an Astro. The Astro map uses the <anchorref> element to
attach the Astro-specific tasks to the general car rental procedure so a
complete, custom definition of the procedure for a preparing an Astro
for rental can be produced.

<map>
...
  <topicref href="carPrep.dita">
    <anchor id="prepDetail"/>
    ...
  </topicref>
  ...
  <anchorref href="#prepDetail">
    <topicref href="astroChecklist.dita"/>
    ...
  </anchorref>
...
</map



> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com] 
> Sent: Wednesday, January 21, 2009 3:23 PM
> To: Su-Laine Yeo; dita
> Subject: Re: [dita] Map structure and possible new attribute 
> for conref push and anchorref
> 
> On 1/21/09 2:09 PM, "Su-Laine Yeo" 
> <su-laine.yeo@justsystems.com> wrote:
> 
> > From the Jan 20, 2009 minutes:
> > 
> > 8. New ITEM: "Conref push for static output formats" discussion
> > * http://lists.oasis-open.org/archives/dita/200812/msg00006.html
> > * http://lists.oasis-open.org/archives/dita/200812/msg00007.html
> > Discussion from Su-Laine Yeo and Michael Priestley ensued. Michael 
> > clarified that there would be a master build map (owned by the 
> > information architect for the product) that the processor 
> would call.
> > How to handle content that should not be displayed 
> anywhere? Su-Laine 
> > stated that this is a problem for anchorref  also. Possibly 
> need a new 
> > attribute. Discussion to follow via e-mail.
> 
> I see this as a general requirement to be able to say "these 
> topics need to be processed but do not contribute directly to 
> any output result".
> 
> While it's not strictly required, it would be nice to be able 
> to do this for topics that are only intended to hold content 
> that is the *target* of conrefs, so that you can have all 
> your topic dependencies made explicit in a map, rather than 
> depending on topic-to-topic dependencies to define the 
> bounded object set of topics rooted at a given map.
> 
> One approach that would not require new attributes would be 
> to use reltables with a specific relationship type to include 
> topics that do pushing. This would remove the need to add 
> additional typing attributes to topicref and would make it 
> clearer that the referenced topics are not intended to be 
> part of the main navigational flow.
> 
> Cheers,
> 
> Eliot
> 
> ----
> Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
> email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of 
> the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com 
> <http://www.reallysi.com>  | http://blog.reallysi.com 
> <http://blog.reallysi.com> | www.rsuitecms.com 
> <http://www.rsuitecms.com> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS 
> TC that generates this mail.  Follow this link to all your 
> TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
>