Mike, It is valid to have the <title> of a <book> inside <info> while the <title> of an included <chapter> is directly under <chapter> (I've got a file open in emacs nxml mode right now that has exactly that situation, and it parses fine).
The limitation is that you can't have a title both inside <info> and directly under the same element, so the following is invalid: <book> <title>...</title> <info><title>...</title></info> ... </book> This, however is valid: <book> <info><title>...</title></info> ... <chapter> <title>...</title> <info>other info stuff</info> ... </chapter> </book> Are you saying that XMLmind complains about the second case above? If so, then either the problem is in XMLmind, or with some other error in the source. You may want to try parsing your instance with another parser to see if there's another problem with the source. I use jing, but there are others. There is a description in the XMLmind documentation (http://www.xmlmind.com/xmleditor//_distrib/doc/rngsupport/index.html) of some situations where the editor can get "lost." For example, if an element matches two possible sub-expressions in the schema as you are editing text and the instance is incomplete, it may not be able to figure out which one you intended and can get confused. That might explain what you're seeing. BTW, as background, in DB5 the info elements were redesigned with two thoughts in mind: 1) Take advantage of Relax NG's ability to give an element different content models in different contexts. So for example, you can define the <info> element in <book> to have a different content model from the <info> element in <chapter>. That isn't done in the standard, but you could do that if you customize the standard. DTDs won't let you do that, so earlier versions had differently named info elements so customizers could do this. That's why you had <bookinfo>, <chapterinfo>, et al. 2) Plug a hole in earlier versions that allowed <title> both inside <info> and outside at the same time for some elements (so the example above that I said was invalid would parse in earlier versions of DocBook). Now, if you look at the 5.0 definition of an element like <chapter>, you will see the following at the beginning: ((title & titleabbrev? & subtitle?), info(db.titleforbidden.info)?) | info(db.titlereq.info), .... That basically says that the first element inside a chapter must be a title (with optional titleabbrev and subtitle), followed by an optional info block that cannot have a title, or it must be an info block that must have a title inside it. There are then variants for elements that don't allow subtitles (example, figure, etc.), and for elements that have optional titles, some of which allow subtitles (dedication) and some of which don't (orderedlist). That's where the five variants come from. However, they only vary wrt titles, the rest of the content model is the same. While that looks a bit complex (I had to re-read The Definitive Guide to make sure I didn't screw it up:), overall, it's a simplification for authors because you get rid of a bunch of identical info elements. It does, however, make parsers work hard, and as Norm will attest, it's at least one factor that makes creating a usable DTD a royal PITA:-). I hope that helps. Richard Hamilton ------- XML Press XML for Technical Communicators http://xmlpress.net [email protected] On Feb 4, 2012, at 9:19 PM, Mike Maxwell wrote: > In DocBook 5, there are apparently five different kinds of <info> elements, > although none of them is distinguished by the tag name itself. When we edit > a <book> including as an immediate daughter this <info> element in XMLmind, > we get an error if the <info> element in turn contains a <title> (or I guess > a <subtitle>). > > I *believe* (but am not certain) that this reflects a problem in the rng > schema, not in XMLmind itself, which simply validates the doc using the > standard rng schema. My guess is that it's using the db.titleforbidden.info > definition of <info> at the book level, rather than the db.info definition. > > I don't however understand how the schema validation chooses which 'info' > definition to use. A similar issue of multiple definitions arises with HTML > vs. CALS <table>s, but if I understand correctly, the validator chooses which > of these definitions of <table> to use based on the daughters of a particular > <table> element. Whereas in this case, it seems to be choosing which > definition of <info> to use *despite* the daughters. > > Over here > http://docbook.org/docs/howto/ > I see footnote b of table 1 says > RELAX NG grammar enforces exclusivity of several elements. > For example if you have title inside info then it is not > allowed to have another title outside info. > In our case, the <book> element has only the single <title>, inside the > <info> element. However, the <chapter>s do have <title>s which are not > inside <info> element. Does the above footnote mean that if you use an > <info><title>...</title></info> structure (i.e. db.info) as a daughter of > <book>, the <chapter>s canNOT have a <title> as an immediate daughter? And > hence the only way for a <chapter> to have a <title> is for it to use a > db.titlereq.info element (since db.info cannot appear as a daughter of > <chapter>). That seems rather odd, not to mention confusing... > > Why this proliferation of different kinds of <info> elements? > -- > Mike Maxwell > [email protected] > "My definition of an interesting universe is > one that has the capacity to study itself." > --Stephen Eastmond > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
