OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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:

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

And map-01.ditamap is:

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

Then the effective resolved map would be:

 <topicref chunk="to-content by-document select-document"
 <topicref chunk="to-content by-topic select-topic"



Eliot Kimber, Owner
Contrext, LLC

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):
>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
>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.
>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.
>Eliot Kimber, Owner
>Contrext, LLC
>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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]