[docbook] *info (was Re: RE : [docbook] Question: address within entry)

[Norman Walsh <ndw at nwalsh dot com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Fr?éd?éric Glorieux <frederic dot glorieux at ajlsm dot com> was heard to say:
| 	I pick up this thread for a more general question on *info.
|
| 	What is the reason why the info block is sometimes coming after
| the title (ex: article, book), and before everything in some other cases
| (ex: section, bibliography)?

Honestly, I think the answer is probably "historical accident". I
note, however, that the distinguishing characteristic is whether or
not the title is optional.

I can't immediately see why putting the optional *info wrapper before
the optional title would create an ambiguous content model, but
perhaps it once did.

| 	To continue, is it in your projects to provide a generic info
| wrapper? This may become very useful with includes (example: as an
| everywhere signature in a project, with some automatic revhistory
| fill-in).

Last time we talked about this in the TC, we added it to a bunch of
likely block candidates. We've avoided adding it to elements that have
mixed content because it would be impossible in those elements to make
the blockinfo occur at most once or even first. In other words, if
blockinfo was allowed in paragraph, the following would be valid:

  <para>Some text <blockinfo>...</blockinfo>
  More text <blockinfo>...</blockinfo><blockinfo>...</blockinfo>
  </para>

That looks like "a bad thing" and there's been no pressure (i.e.
compelling use case) to add blockinfo specifically to mixed content
elements.

| 	Related to this topic, I was sad to read: "Future Changes,
| ArticleInfo will be dropped from the content model of BiblioEntry". I
| understand that the name is not exactly the best (see above), but the
| wrapper allows keeping of important information from bibliographic
| systems (revhistory, keyword, subjects ...).

All of the elements that could appear inside articleinfo are allowed
directly in biblioentry and if it allows you to maintain an important
semantic distinction (what distinction is that?) then you can still
model it with biblio(m)set.

| An info block is a good
| place for that (outside of rendering), and automatic extraction from an
| author bibliography may be used by a full bibliographic system (or an
| indexation engine).

Yep.

| 	For the Committee discussions, I can also suggest to think about
| an inline <subject concept="sujet" thesaurus="rameau">subject</subject>,
| where @concept is the authorized form of "subject" in the "rameau"
| thesaurus (I need to implement the iso 5964 standard on thesauri, I
| would be glad to do it with full compatible docbook).

Is 5964 available online? (As a rule ISO documents aren't, but there
are some exceptions.)

| 	I also notice that <revhistory/> could be in lots of places. I'm
| using it because it's the only place to find <date/> as a list (in spite
| of the <revnumber/>). <calendar/>, <chronology/> or <history/> could be
| better to explain my usages. It's of course of academic or journalistic
| interest, perhaps software documentation can also find usage of it.

There's lots of things we could do, the question is, are there compelling
use cases in hardware and software computer documentation for them?

                                        Be seeing you,
                                          norm

- -- 
Norman Walsh <ndw at nwalsh dot com>      | "I" before "E" except after "C":
http://www.oasis-open.org/docbook/ | simple, concise and efficeint.
Chair, DocBook Technical Committee |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE+ienhOyltUcwYWjsRAvMjAJsEHNoK27nKIOxDDEE1zYkn5j3zcACfVz3d
HyXhqPnCTYClIo8V2hjdBvc=
=BeVq
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-unsubscribe at lists dot oasis-open dot org
For additional commands, e-mail: docbook-help at lists dot oasis-open dot org