[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Jeff's (Arbortext) comments on the DITA 1.1 ArchitecturalSpec...
No one has followed up on our chunking discussion
in today's meeting yet, so while it's still on my mind I thought I'd
offer my two cents. I agree with Paul that the description of the chunk attribute should be more toolkit neutral, and not refer to files as the privileged repositories of chunked topics - since some of us store our documents in CMS and other database systems. On the other hand, as Michael pointed out we do need - not so much a "chunk," as a "do-not-chunk" attribute. Otherwise no automated process is going to know not to chunk topics embedded in other topics to form section-like structures that are not intended to stand on their own - which is the compromise we've built into the standard for these kind of structures. --Dana Grosso, Paul wrote: ...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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]