|
Hi Kate,
I was going to suggest you use sidebar with a role
attribute, but your earlier mail said you were already doing that. I think
sidebar is semantically a good match for "defining/explaining/introducing a
term/option/clause/concept". Most people think of sidebar as formatted to
the side, but it does not have to be. Since DocBook XML markup is not
meant to indicate formatting, a sidebar is intended to indicate content "out of
the regular flow", and which *might* be formatted to the side.
Your original inquiry about formalpara did not seem
to be motivated by formatting issues, but by authoring issues. You wanted
a container for multiple paragraphs so you could move them as a unit. That
kind of need is pretty common, but is often hard to implement in element
structure. I have worked with content in which it was the writing style to
precede every figure and table with a paragraph that explains the relevance of
the following figure or table ("The following figure shows ..."). You can
see how those also have to stay together to make sense, but trying to implement
that combination as an element container would be kind of
awkward. Since DocBook does not support an arbitrary <div>
container, it usually falls on the author to pay attention when moving content
around.
----- Original Message -----
Sent: Tuesday, July 28, 2009 8:03
AM
Subject: Re: [docbook] Why do formalparas
only allow one para?
Hi Bob,
Thank you for your advice and suggestion to submit a
RFE to the DocBook committee.
Perhaps my team isn't using formalparas correctly. Could you explain a
bit more as to how they should be used?
We use formalparas for defining/explaining/introducing a
term/option/clause/concept. It's the assumption/restriction that this
can always be done in a
single para
that is forcing us to resort to other tagging instead (e.g., like just bolding
the term inline in a para, which isn't ideal, or needlessly creating
variablelists).
We desire
multi-para formalparas (to embed a definition in the larger topic, but
differentiated style). We could then bring in the formalpara margins by 3 or 4
spaces to differentiate it from regular paras that follow, etc. :))
Thanks again,
Kate
| "Bob Stayton"
<bobs@sagehill.net>
07/25/2009 12:18 PM
|
|
To
| <Kate.Wringe@sybase.com>
|
|
cc
| "David Cramer"
<dcramer@motive.com>, <docbook@lists.oasis-open.org>,
"Jirka Kosek" <jirka@kosek.cz>, "Scott Hudson"
<scott.hudson@flatironssolutions.com>
|
|
Subject
| Re: [docbook] Why do formalparas
only allow one para? |
|
Hi Kate,
If you want this to be
considered by the DocBook Technical Committee for inclusion in future versions
of DocBook schemas, please file a RFE on the DocBook SourceForge site:
https://sourceforge.net/tracker/?group_id=21935 (select "RFEs")
You must be a member to
submit new items.
I can tell you that such generic container elements have been discussed
in the past but never adopted. Be sure to include all of your arguments
and use cases to support your request.
Bob Stayton
Sagehill Enterprises
bobs@sagehill.net
----- Original Message -----
From: Kate.Wringe@sybase.com
To: Dave Pawson
Cc: David Cramer ; docbook@lists.oasis-open.org ; Jirka
Kosek ; Scott Hudson
Sent: Friday, July 24, 2009 6:17 AM
Subject: Re: [docbook] Why do formalparas only allow one
para?
What we need is a
free-floating container element that takes a title and allows other block
elements (e.g, indexterms, paras, lists, etc.,) within it.
We want a container element because it
is useful for reuse and relocation of content. We want the element to be
free-floating because we need to be able
to put the element anywhere and have other content
elements follow it (including itself).
The problem with bridgeheads is that they are just
titles and you can't show the relationship between the title and the content
that follows it. To xinclude you'd have
xinclude the bridgehead as well as
each element that follows. We would prefer to have one container element that
you could put an ID on and be able to conditionalize it and/or xinclude
it.
We
actually have two cases where we need free-floating container elements with
titles:
1) One
where the title is not inline -- this element would be akin to simplesect if
simplesect was not non-floating.
2) One where the title is inline -- this
element would be akin to formalpara if formalpara allowed you to have more
than one para and allowed other block elements.
Currently for 1) we use sidebars
instead of bridgeheads because we needed a sub-section-level container
element with a title, that could be used anywhere and multiple times within a
section.
Simplesect, because it is non-floating, did not meet our
requirements.
We are looking for a solution for 2) because formalparas do not
meet our needs, but they are the best alternative we have right
now.
Thanks
again,
Kate
| Dave Pawson
<davep@dpawson.co.uk>
07/24/2009 12:25 AM
|
|
To
| David Cramer
<dcramer@motive.com>
|
|
cc
| Scott Hudson
<scott.hudson@flatironssolutions.com>,
Kate.Wringe@sybase.com, Jirka Kosek <jirka@kosek.cz>,
docbook@lists.oasis-open.org
|
|
Subject
| Re: [docbook] Why do formalparas
only allow one para? |
|
Why not use a bridgehead and
multiple paras?
formalpara is singular? Hence one
para?
regards
--
Dave Pawson
XSLT XSL-FO
FAQ.
http://www.dpawson.co.uk
|