Recent changes to publishers-rfe

linegroup and blockquote elements

2013-02-01T01:39:32Z

I'd like consideration given to allowing the <line/> element within <blockquote/> when <blockquote/> is a child of <linegroup/>.
<blockquote/> is allowed as a child of <linegroup/>, but <line/> cannot be wrapped by <blockquote/>

Presently the only way to wrap <line/> within <blockquote/> is to do so, on less I'm missing something, is as follows:

While I'm requesting this I suspect the problem will be what <blockquote/> already allows as its' children.
Thanks for considering.

Restricted poetry markup

2012-08-22T17:25:12Z

This is a placeholder for DocBook Publishers vX where X is a schema based on DocBook 6 as this is an incompatible change.

The content model for poetry is currently far too open. It is hard to see how the allowing tables and lists within poetry can be beneficial. I would like to propose that the linegroup element be restricted as:

db.linegroup =
element linegroup {
db.linegroup.attlist, db.speaker*, db.line+
}

This may be *too* restrictive but we have used similar in poetry markup at Penguin for some years.

Add stage direction markup

2012-08-22T17:21:45Z

There is no support within DocBook Publishers for the semantic markup of stage directions. I'd like to propose the addition of two elements both allowing the standard set of inlines. The first would be a direction (or other suitable name) element, used to provide block level stage directions (between the speeches, etc) and the other would be inlinedirection (or...) to allow for inline stage direction markup.

The following shows the need for an inline direction element:

THE FLOWER GIRL [picking up her scattered flowers and replacing them in
the basket] There's menners f' yer! Te-oo banches o voylets trod into
the mad. [She sits down on the plinth of the column, sorting her
flowers, on the lady's right. She is not at all an attractive person.
She is perhaps eighteen, perhaps twenty, hardly older. She wears a
little sailor hat of black straw that has long been exposed to the dust
and soot of London and has seldom if ever been brushed. Her hair needs
washing rather badly: its mousy color can hardly be natural. She wears
a shoddy black coat that reaches nearly to her knees and is shaped to
her waist. She has a brown skirt with a coarse apron. Her boots are
much the worse for wear. She is no doubt as clean as she can afford to
be; but compared to the ladies she is very dirty. Her features are no
worse than theirs; but their condition leaves something to be desired;
and she needs the services of a dentist].

(from Pygmalion)

Suggested grammar (as RelaxNG compact)

# A stage direction.
db.direction.attlist = db.common.attributes
db.direction.content = (db.para+)
db.direction = element db:direction {db.direction.attlist, db.direction.content }

# inline stage direction.
db.inlinedirection.attlist = db.common.attributes
db.inlinedirection.content = (db.all.inlines+)
db.inlinedirection = element db:inlinedirection {db.inlinedirection.attlist, db.inlinedirection.content }

Add admonitions to Publishers

2012-04-18T05:44:39Z

The admonitions group was removed from DocBook Publishers. Recently, I've been working with vocational textbook publishers who use admonitions fairly extensively. If there is no strong reason for excluding them, perhaps they should be allowed to avoid the workarounds that have been required so far (using sidebars with role attributes)

DocBook Music Notation: Repost

2011-10-23T16:56:22Z

Norm stated that this might be of interest to the publishing committee: http://sf.net/support/tracker.php?aid=3383019

Replacement for "annotation" element

2011-06-12T11:55:44Z

I am currently using the "annotation" element within a book/info for any additional text on the imprint page, such as the description of photos on the front cover, and details about the type used in the book or the printer. I not that the annotation element is to be removed from the Publishers Schema. Would the Working Group consider introducing a new element (eg "imprint") for this miscellaneous information - there does not seem to be another suitable element that can be used as a child of info/.

include mechanisms for table accessibility

2011-04-25T09:34:02Z

The HTML table model allows a better preparation of table structure for (especially screen reader) accessibility when transforming to HTML (and, by analogy, probably to PDF and other digitally accessed output formats too, though I haven't studied this yet).

The CALS table model does not come anywhere near the abilities of the HTML model in associating data cells with table headers.
Especially in complex table setups, a combined use of the HTML-model id and headers attributes is excellent for demystifying the structure of table data - where CALS does not provide any infrastructure that could be used to generate such structuring via XSLT.

Thus, including the HTML table model would cater to accessibility requirements in all publishing contexts transforming docBook content to be accessed online as HTML - and probably also other formats.

References:
Techniques for WCAG2.0: http://www.w3.org/TR/WCAG20-TECHS/H43.html
W3C research on complex tables: http://www.w3.org/html/wg/wiki/ComplexTables
WebAim Guide for accessible data tables: http://webaim.org/techniques/tables/data

Epigraphs should allow poetry

2011-01-31T16:04:51Z

Poetry is a common component of epigraphs in trade and academic publishing. It seems entirely consistent that DocBook publishers should allow this too.

Naming and Versioning of Publishers' Schema

2010-05-23T20:55:24Z

Hi,

the Publishers' Schema Specification [1] describes a lot of details, which is fine. However, there is no section how to name and access the publishers schema. According to [2] there should be naming convention in the version attribute. Does the committee consider this as something worth or is it out of scope?

Thanks,
Tom

--- Reference:
[1] https://docbook.svn.sourceforge.net/svnroot/docbook/trunk/docbook/relaxng/publishers/spec/publishers.xml
[2] http://www.docbook.org/docs/howto/#cust-naming

Formalize the adoption of Dublin Core in the info element

2008-05-14T18:58:51Z

While DocBook already includes many of the elements that are defined by the Dublin Core, it is not inherently interoperable with DC metadata. The Publisher's SC (and hopefully the the DocBook TC) should consider adopting DC metadata as a formal metadata model for <info> elements