DITA Proposed Feature # 17d

conref and conditional processing: delayed resolution for use of DITA as a delivery format

Longer description

Some runtime engines may be able to handle resolution of conref or conditions after the information is built. So the build process will need to distinguish which conrefs to preserve without resolving, which ids to publish as anchors usable by others in a larger environment, and which conditions to strip out of content (eg conditions that mention products not yet announced).

Scope

Major

Use Case

{Describe this feature's use, as if ideally implemented.}

Technical Requirements

  1. Enhance ditaval format to allow specification of values to strip from content being published; alternatively, specify values to preserve (not sure which the default should be). For example: <prop att="platform" action="preserve"> would preserve all values in the platform attribute; <prop att="product" val="myfutureprod" action="stripval"> would remove the myfutureprod value from any published form of the content.
  2. Add domain to identify ids within each topic that should be made public to act as anchors for others to contribute content to. For example, an <exportanchors> element within metadata or topicmeta, specialized off <keywords>, with a list of empty <anchorid> elements with required ids. Could be done in topic or in map.
  3. Defer resolution of conrefs that target exported ids. May want to limit this to ids exported in maps and conrefs that use keyref, since that will be necessary in any case to target content that is not part of the same build.
Figure 1. Source topic
<topic id="abc">
	<title>ABC<title>
	<shortdesc>...</shortdesc>
	<prolog><metadata>
		<exportanchors>
			<anchorid id="xyz"/>
		</exportanchors>
	</metadata></prolog>
	<body>
		<section id="myid">something</section>
		<section product="myfutureprod plusotherprod">another thing</section>
		<section id="xyz">and finally</section>
	</body>
</topic>
Figure 2. Delivered topic - assuming myfutureprod was stripped during ditaval processing
<topic id="abc">
	<title>ABC<title>
	<shortdesc>...</shortdesc>
	<body>
		<section>something</section>
		<section product="plusotherprod">another thing</section>
		<section id="xyz">and finally</section>
	</body>
</topic>
Figure 3. A map used by another team that provides info about the previous topic, including ids they can conref
<map>
	<topicref keys="ABC" scope="peer" href="../someoneelsesdir/abc.dita">
		<topicmeta>
	 		<linktext>ABC</linktext>
			<shortdesc>...</shortdesc>
			<exportanchors>
				<anchorid id="xyz"/>
			</exportanchors>
		</topicmeta>
<map>

keyref is documented in issue 40.

It would be a bonus if we could also generate a map like this during delivery, like a manifest of what's been delivered, to make it easier for others to find the content they can reuse and keep it up to date.

Costs

Some work for toolkit to introduce DITA delivery build that preserves or strips attributes as shown. More work for any delivery vehicle that wants to make use of this.

Benefits

Content that users can customize, by applying their own profiles for conditional processing. For example, a common help set that can be filtered for a particular audience value based on which user is accessing the help.

Content that can be updated incrementally, even by different providers, and even when the content contains dependencies like reuse relationships. For example, a topic on configuring your printer that updates to show the latest settings when the printer is upgraded.

Time Required

4 meetings to agree on design