-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
answering to original post even though I take into account other answers.
General remark: I consider DocBook to be already super rich. And that's
an euphemism: it makes hard to push it to newcomers, especially when
compared to other XML tech doc grammars.
Norman Walsh a 嶰rit :
[...]
> If we decide to do so, I think something along the following lines
> fits into the design of DocBook:
>
> 1. Add a <topic> element with the same content model as <section>
> except that where section allows (sect1|section|simplesect), we
> allow <topic>. So a topic contains subtopics analagous to the way a
> section contains subsections.
I tend to concur with Doug here: why couldn't a topic be structured in
sections? Since a topic is meant to have a specific semantic meaning,
one might not want to organize his topic information in [your semantic
meaning of topic here].
> 2. Give topic a class attribute so that authors can have different
> kinds of topics. DITA has all this funky weirdness about the
> content models of various kinds of topics; I don't think we should
> go there.
Agreed, one can always implement schematron rules to enforce project
specific requirements.
> 3. Allow topic as an alternative to (chapter|appendix|preface) in books.
> This allows one to have a book of topics.
Wouldn't that wipe the main difference between a book and an article?
> 4. Allow topic as an alternative to (sect1|section|simplesect) in
> chapters and appendixes. This allows one to have a chapter of
> topics.
Given the above and the obvious similarity between a section and a
topic, I'd rather suggest to specialize the section element with an
attribute (type="topic"?). That would allow further specializing section
(which is a renowned modular element).
> As a slight extension of this model, we could also add a <tasktopic>
> element. This would address the feature request[1] for "task" as a
> peer to "section". If we did this, then I'd expect "topic" or
> "tasktopic" to be allowed anywhere I've mentioned topic above.
Wouldn't a topic containing a task serve the same purpose?
> Given that topics are often composed in a fairly arbitrary order for
> publishing in print, we might want to consider adding a "contentmap"
> element as well for describing the order of topics. But we might be
> able to get "toc" to serve this purpose.
How would that differ from an article containing a hierarchy of sections
and xincludes to topics?
Camille.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFQcHejv9P65BfOUMRAltUAKCGg8Tn1lqKL1Dy5r1wy3PC/5O6rQCfXSXt
QukVGIvNDNCgdEG8AIA9Y4s=
=29LO
-----END PGP SIGNATURE-----
