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] Chunking: resource name selection based on @keys


I like the new rule, but I think it only needs the first sentence. The rest consists of two MAYs (which are implicit - anything not explicitly prohibited is allowed) and an example. The phrase "constructed using" is vague enough to allow processors to implement, at their discretion, any of the various options enumerated in that language.

Chris

Chris Nitchie

(734) 330-2978

chris.nitchie@oberontech.com

www.oberontech.com

cid:image001.jpg@01CE6901.A84DFC50

Follow us:

cid:image004.png@01CE6903.8131DC70

cid:image005.png@01CE6903.8131DC70

cid:image006.png@01CE6903.8131DC70

 

 



From: Robert D Anderson <robander@us.ibm.com>
Date: Monday, December 8, 2014 at 4:07 PM
To: "dita@lists.oasis-open.org" <dita@lists.oasis-open.org>
Subject: [dita] Chunking: resource name selection based on @keys

Referring another DITA 1.3 spec comment to the TC for discussion.

The chunking process can be used to create split or combine source documents, and the spec topic provides a set of rules to follow for determining the new name for those resources. Eliot has suggested adding a new rule to the list, but it contains normative language so I don't think it can be added without TC approval.

I've already incorporated a couple of suggested minor wording edits here. With those changes, the lead-in text and items one through 4 make up the current language. I've copied in Eliot's suggested change after item 3, including the commentary from DITAWeb.

    When creating new documents via chunk processing, the resource 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 resource name SHOULD be taken from the resource name of the map.
    2. If the @copy-to attribute is specified, the resource name MUST be taken from the @copy-to attribute.
      • Insert new item 3 following this item:

        If the @copy-to attribute is not specified and one or more keys are specified on the topicref, the resource name SHOULD be constructed using one of the keys. Processors MAY provide different options for choosing among multiple keys, with selection of the first key in the @keys value suggested as the default behavior. When the topic reference is within a named key scope, processors MAY use the fully-qualified key name or any intermediate qualificatied name as appropriate. For example, the organization of the source files may be such than an unqualified key will be unique within the current directory or an output processor may require that all resource filenames be globally unique.

        WEK Commentary: This rule reflects the fact that keys are more reliable than topic IDs for the purpose of generating names, because they are both reliably unique within their applicable scopes and under the control of the map author, while topic IDs are not.

        Because this as SHOULD rule, processors are free to ignore this rule, so processors that only implement the topic ID rule will continue to be conforming. 
    3. If @copy-to is not specified and the by-topic policy is in effect, the resource name SHOULD be taken from the @id attribute of the topic.
    4. If @copy-to is not specified and the by-document policy is in effect, the resource name SHOULD be taken from the resource name of the referenced document.

To view the list (and comment) in DITAWeb, see
http://ditaweb.com/oasis-dita/#/00074601-DA$00074073-DB$Using%20the%20@chunk%20attribute

Thanks,

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)


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