Re: [dita] Need to Relax Rule for Generating Chunk Names

[Eliot Kimber <ekimber@contrext.com>]

In addition, we need to clarify that when @chunk is set on the root map it
overrides any values set on subordinate @map elements but, by the same
token, if @chunk is not set on a higher map then the value set on a submap
governs. If @chunk is set on a map-referencing topicref that value takes
precedence over a value specified on the referenced map.

For example, if the root map is:

<map>
  <mapref href="map-01.ditamap"/>
  <mapref href="map-01.ditamap" chunk="to-content by-topic select-topic"/>
</map>

And map-01.ditamap is:

<map chunk="to-content by-document select-document">
 <topicref href="topic-01.dita"/>
</map>

Then the effective resolved map would be:

<map
 <topicref chunk="to-content by-document select-document"
   href="topic-01.dita"
 />
 <topicref chunk="to-content by-topic select-topic"
   href="topic-01.dita"
 />
</map>

Cheers,

E.

—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com




On 4/8/14, 3:16 PM, "Eliot Kimber" <ekimber@contrext.com> wrote:

>In DITA 1.2 and still in DITA 1.3 the rules for generating resource names
>as a result of to-content chunk processing are (from the topic "Chunking"
>in the Arch Spec):
>
>[quote]
>When creating new documents via chunk processing, the storage object name
>or identifier (if relevant) is determined as follows:
>
>1.If an entire map is used to generate a single chunk (by placing
>to-content on the map element), the name is taken from the name of the
>map.
>
>2. If the @copy-to attribute is specified, the name is taken from the
>@copy-to attribute.
>
>3. If @copy-to is not specified and the by-topic policy is in effect, the
>name is taken from the @id attribute of the topic.
>
>4. If @copy-to is not specified and the by-document policy is in effect,
>the name is taken from the name of the referenced document.
>[/quote]
>
>
>In this set of rules, rule (3) is currently written as a MUST statement:
>"the name *is taken* from the @id attribute"
>
>
>This is too restrictive because it doesn't make any allowance for
>processors to handle the case where two different chunks would have the
>same resource identifier, e.g. "topicid.dita" because the topics happen to
>have the same ID. (As it happens, the OT today handles this case by
>generating a unique resource ID for the chunk, which is technically
>non-conforming by the language quoted here.)
>
>Robert and I are in agreement that this MUST should be a SHOULD and we
>should add some language to clarify what processors are allowed to do,
>something like:
>
>"
>If @copy-to is not specified and the by-topic policy is in effect, the
>resource identifier SHOULD be taken from the @id attribute of the topic.
>When two such resource identifiers would conflict processors MAY recover
>by generating resource identifiers, for example, by combining the resource
>identifier of the target topic's XML document and the topic's @id value.
>
>"
>
>The spec intent is to encourage consistency and predictability of the
>generated resource identifiers, but the rule as stated in DITA 1.2 does
>not satisfy that requirement without effectively imposing the requirement
>to either use @copy-to in all cases where IDs are not reliably unique or
>to modify your content to make topic IDs globally unique where they
>otherwise would not need to be.
>
>By contrast, a combination of the XML document filename and the topic ID
>will always be unique within the same directory because you can't have two
>XML documents with the same filename in the same directory and you can't
>have two topics with the same ID in the same XML document.
>
>Cheers,
>
>E.
>
>—————
>Eliot Kimber, Owner
>Contrext, LLC
>http://contrext.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_workgroups.php
>
>