Re: [dita] Stage 1 proposal: redesign chunking attribute

[Chris Nitchie <chris.nitchie@oberontech.com>]

I like the simplicity of this. Literally every chunking scenario I've ever personally run into has been combining a branch into a single output chunk, such that chunk="to-content" (or, under this proposal, chunk="merge"), would suffice. So this works.

Would there be value in a third value of 'toc'? When you have a topicref to a topic that has nested topics, chunk="toc" would cause ToC entries to be generated for the nested topics, but would leave them in a single output chunk. I don't think this is possible with the current @chunk attribute, unless it's what to-navigation is for, but it strikes me as a reasonable use case.

The main thing this proposal does away with is the select-* tokens, but I'm not going to miss them. That said, I do think that the 2.0 spec needs to mandate that default topic selection processing should be what we're currently calling "select-branch". That is, when referencing a specific topic in a resource with many topics, only the selected topic and its descendants should be included in the output artifact for that topicref. The default processing in the OT the last time I checked - which, admittedly was a few years ago - was select-document, so you'd get the whole ditabase/compound topic file in the output, with the ToC entry pointing to the appropriate anchor. With the proliferation of map-based contextualization capabilities - scoped keys, ditavalref, collection-type-mandated inter-topic links, etc. - I don't think that processing makes much sense anymore.

I'm fine with a 'none' value for a processing or DTD default value. However, I have concerns about using it as a 'stop chunking here' instruction. Consider:

<topicref href=”a.dita” chunk=”merge”>
    <topicref href=”b.dita”/>
    <topicref href=”c.dita” chunk=”none”/>
    <topicref href=”d.dita”/>
</topicref>

I don't know what this is trying to express. My best guess would be two chunks, one with a/b/d and another with c, with ToC links pointing to the appropriate locations within the two chunks. But I question the utility of that, and worry that it’s just re-introducing some of the complexity and potential for confusion we’re trying to get away from. I think maybe @chunk attributes inside a branch with chunk="merge" should be ignored.

Chris

From: <dita@lists.oasis-open.org> on behalf of Robert D Anderson <robander@us.ibm.com>
Date: Wednesday, February 28, 2018 at 5:25 PM
To: DITA TC <dita@lists.oasis-open.org>
Subject: [dita] Stage 1 proposal: redesign chunking attribute

I know I've complained about this attribute many, many times, and described it as one markup item sure to change in DITA 2.0.

A long 1.5 years ago I sent some thoughts about this to the list as a suggestion for 2.0, but this was before we even had the stages set up and it's not listed in any of our issues / cards:
https://lists.oasis-open.org/archives/dita/201606/msg00035.html

That email resulted in some good thoughts / suggestions. I'd like to propose this as a stage 1 item for initial discussion, based on that initial idea, and hopefully can get one of my stage 2 / 3 proposals finished off soon enough to take this on as a stage 2 proposal.

The basic stage 1 level idea -- laid out in that email, with some additional thoughts since then -- is as follows:
1. Discard the old chunk values because they are not intuitive and/or generally unused.
2. Define new, intuitive / meaningful tokens used on the same attribute.
3. Leave the attribute as CDATA (Chris expressed some understandable reservations at the time), meaning this change on its own doesn't result in DITA 1.3 markup that won't parse in DITA 2.0
4. Initial idea expressed in that email was to have values "merge" (combine this topic with nested topics in the branch) and "split" (turn this document of many topics into many documents). I've since also come to wonder about third value that's basically a way to say "Even if everything above me was getting chunked into one file, return to whatever my application considers normal at this point." Perhaps a value like "normal" or "default" or "none".
5. For the lesser or never-used edge cases - like selecting and publishing a single topic from a document that has many topics - leave that up to applications to define, and/or leave that up to somebody else on the TC to define as a different attribute.
Regards, 
Robert D. Anderson 
http://dita-ot.org/ lead and Co-editor http://docs.oasis-open.org/dita/dita/v1.3/os/part0-overview/dita-v1.3-os-part0-overview.html,
Digital Services Group 


E-mail: mailto:robander@us.ibm.com
https://w3.ibm.com/digital/

11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA