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] DocBook 5.0: The Definitive Guide


On Tue, 2005-01-04 at 08:05 -0500, Norman Walsh wrote:
> Over the winter break, I spent some time building a "V5.0"
> version of DocBook: The Definitive Guide. You can find it at
> http://docbook.org/tdg5/en/

Another quiet Christmas Norm (and Debs :-)????

Comment, tdg5.

Why does the content  model appear twice please?
The (in cases very long) list of items at the top,
then again as a list of children?
 Two comparisons:

answer and affiliation.

answer is a simple, long list at the top, a more compact comma separated
one at the bottom.
affiliation provides the various occurrences in the list, which
demonstrates the utility. 
  Unsure if the comma separated list with markers (DTD style / rnc style
perhaps?) would present this info comprehensively? I.e. some way
of quickly answering 'can I have this element here'?
  Would that be too terse? With examples and descriptions, the pages
are going to get pretty long?

(And are you deriving the content models from the schema, you
clever .... :-)


I like the phrase (db.phrase) style notation. 

except, perhaps
info (db.titleforbidden.info)

Since its an info element, could it (should it)
be db.info.notitle? 

Mmm. Found a few more
info (db.info), info (db.titleforbidden.info), info (db.titleonly.info),
info (db.titleonlyreq.info), info (db.titlereq.info).

Is there logic there, (or should there be !)

informaltable (db.cals.informaltable)  could that be
db.informaltable.cals (or .html)  with similar logic
to that above? I.e. the element, then the descriptor?



Is the db. prefix essential?

indexterm is shown empty, yet is described as  a wrapper :-)

Do we need the rev, date and time on every page?


inlineequation shows 
 One or more of
  db._any.mml

Wozzat please?
OK, found it.
http://docbook.org/tdg5/en/html/_any.mml.html

I'm less happy with that notation Norm.
If we assume lots of namespaces may creep in over the next n years,
then its worth getting this good now?

will there be _any.xhtml, _any.svgml  etc?
  Brain dump.
   mml:*   
   xhtml:*
   svg:*
   *:* 
(sort of reads more like 'stuff from *this* namespace' to me?)
or perhaps mml:any etc?

I think I basically don't like the underscore starter?
any would be near the top, as would * in the index.
  (I'll stop rambling now)


HTH, 


-- 
Regards, 

Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]