Re:
>Chunking would be better controlled by something
that is aware of the
>output type; building information that is likely to be output type
>dependent into the DITA map, or worse the DITA topics, is a mistake.
Note that maps are aware of output type to some degree,
eg there are print and linking attributes in the map. Given that high-level
structures (such as TOCs or linking maps) are likely to vary from output
type to output type, the DITA map/topic dichotomy is explicitly meant to
insulate topics from output-specific decisions in maps. It seems to me
that the chunk attribute is logically something that belongs in the map
because it is the same kind of output-specific decision as whether/how
to link, etc.
That still leaves the question of whether the default
should be based on source chunking rules or on programmatic rules. This
may come down to a question of what the author's primary experience is:
- if coming from an HTML or online help background,
chunking source and output as the same by default should feel pretty natural:
it's the way HTML websites are authored, it's a familiar set of defaults,
and the chunk attributes provides additional control that you'll only need
when you get into reusing contexts.
- if coming from a print or PDF background, all that
source chunking probably seems like a lot of work, and given that the information
is often sourced in chapter-sized files, the resulting proliferation of
topic chunks probably seems much more complex. So a rule-based system is
much more attractive, and the chunk attribute seems like pointless overhead
that introduces needless complexity.
So: what happens when we get two collections that
have been authored with different assumptions in mind? How do we preserve
the fact that one collection was authored with the chunks chosen for output
effect, and another collection was authored with the chunks chosen purely
for internal reasons? The chunk attribute seems like one way we could
set/expose this behavior - for example, set overall rules on the map element,
and leave it to the map-authoring application to set the map-level chunk
attribute based on the rules implicit in the current authoring/production
system. This might add the need for a new chunk attribute value, eg "topic",
to set chunking to generate a separate output file for each topic.
That still leaves the question open as to what the
default should be (topic, or file) - but it does provide a way for the
two chunking methodologies to co-exist peacefully. CMSs that burst at the
topic level, for example, would simply make sure the map chunk attribute
was set to chunk="topic", and leave it to the author to define,
within the map, what exceptions there were to that rule.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
...are attached (annotated PDF--I hope this will make
it through the
OASIS mailer).
Some of them are very editorial, but others are more major.
We are still working on the language spec.
Much as we'd all like to get 1.1 out, there have been some major things
(like the chunking writeup) that we've only recently had a chance to
review.
Arbortext has a concern with the fact that DITA 1.1 chunking support
calls for the default behavior to preserve the authored chunking as
represented by files. It might be OK to have this behavior be one
of
the options that is supported, but we do not believe it is a good
default (even if it is how the DITA Open Toolkit works today). Chunking
should not be controlled by the topic author. Chunking should be
a rule
based process that is driven forward by hints provided in the map. And
bursting documents into a CMS confuses this whole business even more.
The current DITA 1.1 approach to chunking doesn't seem to have the right
split of control between the map, topics, and output processing.
Chunking would be better controlled by something that is aware of the
output type; building information that is likely to be output type
dependent into the DITA map, or worse the DITA topics, is a mistake.
Chunking would be better controlled from the ditaval file or a style
sheet, possibly using hints in the document.
FWIW, we also remain uneasy about including ditaval in the DITA 1.1
spec. Reread the ditaval section in the Architecture Spec makes it
clear that ditaval is too much about formatting rather than content and
so does not belong in the DITA Standard in its current form. For
example it has the ability to control color, underline, italics, bold,
and specific instructions on how to flag an image. All of that should
be controlled by a stylesheet and not embedded in the ditaval file. The
ditaval file might reference a style name or property to use in some
fashion, but the details should be left to other processes that know the
output type and other information related to the final format.
paul
[attachment "ditaspec22Jan2007bjco.pdf" deleted by Michael Priestley/Toronto/IBM]