[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]