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

["Su-Laine Yeo" <su-laine.yeo@justsystems.com>]

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

I believe you could do it this way:

Map for cars in general, with filename of "car.ditamap" :
<map>
...
  <topicref href="carPrep.dita">
    <topicref id="prepDetail"/>
    ...
  </topicref>
  </map

Map containing Astro-specific procedures:
<map>
    <topicref href="astroChecklist.dita" conref="car.ditamap#prepDetail"
conaction="pushreplace"/>
    ...
  </topicref>
...
</map

(Note that the example that Bruce copied from
http://www.oasis-open.org/committees/download.php/26129/IssueMapConvenie
nces12047.html assumes that the <anchor> and <anchorref> elements are in
the same map. It is more realistic to assume that the content being
pushed and the target context for the pushed content are in different
maps.)

Cheers,
Su-Laine


Su-Laine Yeo
Interaction Design Specialist 

JustSystems Canada, Inc.
Office: 778-327-6356 
syeo@justsystems.com
http://na.justsystems.com 


-----Original Message-----
From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com] 
Sent: Wednesday, January 21, 2009 1:27 PM
To: Eliot Kimber; Su-Laine Yeo; dita
Subject: RE: [dita] Map structure and possible new attribute for conref
push and anchorref

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 
> 
> 

---------------------------------------------------------------------
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_workgroups.php