OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[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]