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

[Frédéric Glorieux <frederic dot glorieux at ajlsm dot com>]

	Thanks for this answer, sorry to be long

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

	You are right to keep this line, that's the best way to keep
something coherent for your community, and I add, that's why it's a
model for others. You understood that's my questions are coming from two
opposite directions, the needs of our company (software documentation),
and our clients (academic organisations).

[about <revhistory/>, and why not <calendar/>]

	It seems to me that something like a <vCalendar/> compliant
model could be of general interest for software projects (project more
than documentation, I'm agree). It could be a kind of list (a bit like
<procedure/>), with <event/> item. Production of such types is already
possible with the mozilla XML.vCalendar implementation.
	 For the moment we are matching <revhistory/> with some
different @role or contexts (in *info, it's about the doc, in the doc
it's a data).	

> 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.

	OK. For us it's not a big problem, because we are building
everything on <section/>, to keep fully recursive blocks (something
written here for them, could appear with some more changes, in another
place for others).

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

	Very bad, indeed. We will then need another element in <para/>
to contain mixed content. But why not in <formalpara/> (in hope to have
correctly check the DTD itself, and not only the doc)? Other case (where
we had to customize docbook for an organisation), where to put a <para/>
to describe an <authorgroup/>? 
	And also, why not a generic info wrapper everywhere as an
alternative to all *info? 
	I was writing a docbook.css these days, it's not easy but
possible to give different rendering to the generic <title/> everywhere
with a CSS selector syntax compliant to Xmetal and Internet Explorer
(there is the goal, IE don't see '>' child axis, Xmetal don't match the
!important rule). So now, I'm not afraid to match the same <info/>
everywhere it could be, especially in good xsl-xpath.
	Perhaps you will not like this example but among all their
defaults, TEI provide a generic <head/> element as first child of all
non mixed content. What's your opinion on that?

> 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.

	I'm not sure to be right, but I check the doc and the DTD from
CVS,
<!ENTITY % info.class
		"graphic | mediaobject | legalnotice | modespec
		 | subjectset | keywordset | itermset |
%bibliocomponent.mix;
                 %local.info.class;"> 

	Should I understand  that <subjectset/> and <keywordset/> are
not in your bibliographic model? Our bibliographers are very proud of
their authorities lists and topics. They would be sad to lose them in a
docbook export. The distinction I made (which is not mine in fact),
could seems a little detail in scope of a book, but important for
bibliographers. I remember that's there's no global elements in docbook
(very useful for includes), and a <biblioentry/> could become a full
document in some contexts.
	A <biblio(entry|mixed)/> give a displayable notice, an <info/>
block can say more on the status of this record. To give an example,
<rehistory/> in the record is talking about the book (ex: draft in 1647,
written in 1653), in an info, it's talking about the bibliographers who
notice the book (ex: registered yesterday). 
	About <subject/>, it's probably better to let in an info block,
as an interpretation of cataloguers (when title, author can't change).
Your biblio(m)set proposition can't resolve this problem, because it's
the same for analytic/articles references.
	To give a real life example. An archaeologist is writing an
article (for the moment, it's an MS.Word document). He takes some
bibliographic references from his organisation library, but also, finds
new good references for his article. The bibliographer asks him to add
his new titles to the common base, sometimes it's the archaeologist,
sometimes it's the bibliographer (from the article). 
	I'm working for a national archaeological agency (French
ministry of culture), they have central SQL database of kind of
"articles", and "biblioentries", and lots of local organisations, with
their own bibliographical systems, and ways to keep and publish their
articles. You have understood that a common XML schema could be useful
for them for 1) standard exchange, 2) production (already for some,
perhaps never for others).
	Keeping full docbook conformance is important; it means open
standard, and also, less deployment problem (you can always download
your work tool at www.docbook.org). We are not a lot to give "pressure"
(France is only able to complain about wars, and ask for pardon when the
good ones will have win), but if it's not too much in the DTD, be sure
to have all contributions we are able to produce.

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

	We bought here (and implement it on our cocoon base publishing
XML platform, http://savannah.nongnu.org/files/?group=sdx). The book has
an hundred pages, but the idea is quite thin. We understood a thesaurus
as a full recursive dictionary of concepts (like genders/species tree
for animals), with more than one form (term) for each concept, and
transversal see-also.
	Took for example the TGN/getty geographical thesaurus
(recommended by Dublin Core,
http://www.getty.edu/research/tools/vocabulary/tgn/index.html).
You can refers to it quite correctly in an info block as <subjectset
scheme="TGN"><subject id="???"><subjectterm>Paris</... The TGN id can
give the info World/America/USA/Texas/Paris (and not capital of France).

	Now, why not have the same info inline? <personname/> is working
in this sense, a generic <name/> wrapper could be interesting (like
TEI). We haven't the best solution (but more than one, incomplete and
with defaults). That's why your advice is welcome (and why not, an
official docbook DTD proposition).
	It could be also of software interest. There's more than one
initiative to keep lists of general computing vocabulary. They are
usually flat, in spite that some hierarchy could be interesting
(XML/(XSL|RelaxNG), XSL:kind of XML, searching XML can also find XSL and
RelaxNG). But they have all the need to distinguish a concept with more
than one term, especially to localize:
computing (computing|computer|informatique|ordinateur) / (
	software (software|logiciel|programme) |
	hardware (hardware|materiel)
)
	One step more, have a docbook type to express a thesaurus. Last
one, give an inline version (like index), to generate (or nicer, to
populate), one or more thesaurus from a book.


	If you have time or fun to think about those kind of things...
help welcome.

	Fred. 



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