[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook] Add topic element to DocBook?
-----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 écrit : [...] > 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-----
begin:vcard fn;quoted-printable:Camille B=C3=A9gnis n;quoted-printable:B=C3=A9gnis;Camille org:NeoDoc adr:Domaine du petit Arbois BP 88;;CEEI;Aix en Provence Cedex 4;;13545;France email;internet:camille@neodoc.biz tel;work:+33.4.42.22.62.35 tel;cell:+33.6.33.15.10.23 note;quoted-printable:Rejoignez mon r=C3=A9seau sur viaduc:=0D=0A= =0D=0A= http://www.viaduc.com/invitationpersonnelle/002lm14bc0jlkfk x-mozilla-html:FALSE url:http://neodoc.biz version:2.1 end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]