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