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] Letting components be empty


Hi Norm,
How about this approach instead?  Leave the original definition of 
db.toplevel.blocks.or.sections

db.toplevel.blocks.or.sections =
  (db.all.blocks+, db.toplevel.sections?) | db.toplevel.sections


and change this to:

db.component.contentmodel =
  (db.navigation.components*,
  db.toplevel.blocks.or.sections,
  db.navigation.components*) | (db.navigation.components)*

The part before the "|" has to have something, but the part after does not.  Does that 
relieve the ambiguity?  And this could be expressed in DTD syntax as well, no?

Bob




"Bob Stayton" <bobs@sagehill.net> writes:
> 6.  DocBook assembly.
>
> Bob raised RFE 3368297 to allow hierarchical elements to
> be empty except for title.  The expectation is that
> such empty elements would be populated during the
> assembly process.  Basically the content models would
> change from using + to using * for block and sections.
> Since this loosens the content models, the change would
> be backwards compatible.
>
> Proposal to accept 3368297 was approved.

This has some interesting consequences. Right now, the content model
of a component is

  db.navigation.components*, db.toplevel.blocks.or.sections, db.navigation.components*

In other words, there are some navigation components (toc, glossary,
index, etc.) that can occur (optionally) at either the beginning or
the end. Between them there must be at least one block-level element
or section.

The change agreed above makes the middle part effectively:

    (db.all.blocks*, db.toplevel.sections*)

Which means you can have blocks (optionally) before the first section
then (optionally) any number of sections.

That makes the component content model:

   db.navigation.components*, db.all.blocks*, db.toplevel.sections*, 
db.navigation.components*

which is, I believe, ambiguous in XSD. It's certainly not valid in a
DTD.

That suggests that to make an XSD or DTD, we'll wind up with

  (db.navigation.components | db.all.blocks | db.toplevel.sections)*

which is...just so bad. One more reason why y'all ought to be
pressuring your tool vendors for RELAX NG support!



Bob Stayton
Sagehill Enterprises
bobs@sagehill.net


----- Original Message ----- 
From: "Norman Walsh" <ndw@nwalsh.com>
To: <docbook@lists.oasis-open.org>
Sent: Wednesday, July 20, 2011 1:48 PM
Subject: [docbook] Letting components be empty




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