This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [docbook] Re: DocBook 5.0: The Definitive Guide


On Wed, 2005-01-05 at 09:23 -0500, Norman Walsh wrote:

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


> 
> Is the list of parents useful?

I think so. It answers the 'can I put this here' question.

> 
> | (And are you deriving the content models from the schema, you
> | clever .... :-)
> 
> Egad, of course! Anything else would be insane :-)

Yah, show-off :-)
They stylesheet to do that, with a bit of a:documentation,
would make a useful tool for other schemas.

> 
> | 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? 
> | Is there logic there, (or should there be !)
> 
> Well, there are five kinds of info element that are used in different
> places.

> 
> db.info -- the general case, anything allowed
> db.titleforbidden.info -- no titles allowed
> db.titleonly.info -- only title allowed, no subtitle
> db.titleonlyreq.info -- only the title and required
> db.titlereq.info -- required title

Sorry, I was getting at the order in which they appeared?
I don't think that's consistent. 
If the element is essentially info, then an approach
might be

db.info.titleforbidden
db.info.titleonly
db.info.titleonlyreq
db.info.titlereq





> 
> | 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?
> 
> But the info is the element not the descriptor above.

My logic was that 'informaltable' is the element,
hence db.informaltable.cals would follow the same pattern
as above  (pattern, not element name :-)


> 
> | Is the db. prefix essential?
> 
> Alas, yes. Pattern names aren't namespace qualified so if you might
> want to use RELAX NG and TEI together, you better make sure that the
> pattern names don't clash.

OK. 



> |
> | will there be _any.xhtml, _any.svgml  etc?
> |   Brain dump.
> |    mml:*   
> |    xhtml:*
> |    svg:*
> |    *:* 

I still like this approach (mainly from the index pov)


> | (sort of reads more like 'stuff from *this* namespace' to me?)
> | or perhaps mml:any etc?
> 
> Some improvement is defnitely needed here.
> 
> | 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)
> 
> Please don't, it's all good stuff.


OK.

regards DaveP






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]