[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Map structure and possible new attribute for conref push and anchorref
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. ------------------ Here is a summary of the overall user goal we discussed in the meeting: Using this example: - Folder1 containing a file called defaultmap.ditamap and a file called default.dita. The map contains a topicref to default.dita. - Folder2 containing a file called pushmap.ditamap and a file called push.dita, where the push.dita topic has a <step> to be pushed into a set of steps in default.dita. The map contains a topicref to push.dita. We want the author of the Folder1 contents to not have to know anything about the contents of Folder2. The author of Folder2 must be able to produce a deliverable that resolves conrefs pushed from push.dita into default.dita. One way for the author of Folder2 to do this is to create a third map called masterbuild.ditamap, with contents as follows: <map> <topicref href = "Folder1/default.ditamap" format = "ditamap/> <topicref href = "Folder2/pushmap.ditamap" format ="ditamap"/> </map> The author of Folder2 and of masterbuild.ditamap can then process masterbuild.ditamap to create deliverables. A problem with using master build maps is that, given current processing rules, processing masterbuild.ditamap, the contents of pushmap.ditamap would appear in output. Using the toc attribute will not solve the problem as the toc attribute suppresses topics from the table of contents but not the body of the deliverable. In PDF output the contents of pushmap.ditamap would appear to be dumped at the end of the document. Also, the toc attribute does not necessarily prevent the topics of pushmap.ditamap from appearing twice in search results or indexes, as the behaviour of the toc attribute with respect to search and indexes is undefined. Therefore, a new @appear attribute which would completely suppress pushmap.ditamap from the toc, the body of the document, and other access points such as search and index, would be useful. There are other ways to solve this problem, but a new attribute is one obvious solution. I briefly mentioned in the meeting that we have a similar problem with anchorref. To explain further, the <anchorref> element proposed here: http://www.oasis-open.org/committees/download.php/26092/IssueMapConvenie nces12047.html is similar to conref push in that it is also intended to allow pushing of content from one independent content set into another. A master build map would also be needed with topicrefs to both the default map containing the <anchor> and the pushing map containing the <anchorref>. The <anchorref> proposal currently says, " The copied child elements can be suppressed in the current context by setting the toc attribute on the child elements to "yes" and on the <anchorref> element to "no"." As I explain above, setting a toc attribute would not suppress anything from the current context, so I think the @appear attribute is what we'd need on this as well. As an aside, I am not sure why we need to add a new <anchorref> element when it seems to do the same thing as conref push. Regards, Su-Laine Su-Laine Yeo Interaction Design Specialist JustSystems Canada, Inc. Office: 778-327-6356 syeo@justsystems.com http://na.justsystems.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]