[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE : [docbook] *info (was Re: RE : [docbook] Question: address within entry)
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]