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] Why do formalparas only allow one para?



Hi Bob,

Thank you for your suggestions and patience. My original inquiry was perhaps motivated more by authoring issues than by formatting issues; however,
these two issues often overlap and are difficult to separate. Also, it is not always apparent why some elements have the restrictions that they do (e.g., why does
para allow block elements like mediaobject?).

At the end of this discussion, I still don't understand the purpose of formalparas and because of usability issues(i.e., there is a problem with distinguishing the paras that follow them),
I'm now inclined to avoid them entirely.  Likely, I will suggest to my team that we use variablelists or sidebar elements instead of formalparas; however, I'm not keen on either alternative as they
will require us to use attributes. For our content, variablelist is probably the better choice; although the writers won't like it because they can't just drag and drop a varlistentry as freely as you
can with formalpara (i.e., you have to ensure that the variablelist  container exists).

Thanks again,
Kate




"Bob Stayton" <bobs@sagehill.net>

07/28/2009 08:07 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,
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.
 
Bob Stayton
Sagehill Enterprises

bobs@sagehill.net
 
 
----- Original Message -----
From: Kate.Wringe@sybase.com
To: Bob Stayton
Cc: David Cramer ; docbook@lists.oasis-open.org ; Jirka Kosek ; Scott Hudson
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





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