Re: [docbook] Too Strict Content Model for abstract?

From
Fekete, Róbert <>
Date
2015-02-04T06:56:20+00:00
ID
CAAhEgppKNyNycKA=
Thread
Re: [docbook] Too Strict Content Model for abstract?
Hi, 

I agree with Thomas, I also dislike embedding not-inline elements in <para>.

@Simon: A wrapper element that could group any other elements would be immensely useful for single-sourcing. Currently I use <topic> for that, and have a preprocessing script that deletes the <topic> tags after xincludes are resolved, but that makes validating documents a pain.

Regards, 

Robert

On Tue, Feb 3, 2015 at 5:45 PM, Dew, Simon <> wrote:
Sorry Thomas, I see someone replied to you directly :-)

FWIW, I agree with you. I only use <para> with inline / text content

myself, as if it were <simpara>. I've sometimes wished there was a

semantically empty wrapper or div element in DocBook to meet the

requirements that Aaron notes.

Simon Dew

Technical Author | Stanley Security Solutions

1 Park Gate Close, Bredbury, Stockport SK6 2SZ, U.K.

 | +44 (0) 161 406 3400

www.stanleysecuritysolutions.co.uk

Registered Office: Stanley House, Bramble Road, Swindon

Registered in England and Wales No. 181585 VAT No. 232 2446 95

On 03/02/15 16:33, Aaron DaMommio wrote:

> Copying the list.

>

> You have some interesting points, Thomas. I'll add that another reason I

> like to put lists inside of their introducing paras is that in my xml

> editor, that means I can grab the whole semantic unit as one object.

>

> And further to my point about reuse...it's often important to put a

> whole concept in a single element in order to use it with an xinclude,

> so combining the list into its introductory para helps with that too.

> --Aaron

>

> On Tue, Feb 3, 2015 at 10:26 AM, Thomas Schraitle <

> <mailto:>> wrote:

>

>     Hi Aron,

>

>     On Tue, 3 Feb 2015 10:11:32 -0600

>     Aaron DaMommio < <mailto:>> wrote:

>

>      > Aha, I see where you're going with that. I have completely the

>      > opposite preference: I typically prefer lists to be contained within

>      > the paragraph that introduces them. That makes more sense to me

>      > functionally. When editing or reusing, it means you have access to

>      > either the para (as a container of itself and the list) or the list

>      > alone. I don't see that you give up any flexibility that way.

>

>     Ah, that's interesting. :)

>

>     Maybe it's a matter of taste, but for me a paragraph is text and (maybe)

>     some inline elements. For me it doesn't make sense to "insert" a block

>     element into a paragraph. Block elements are per se an interuption

>     of the

>     normal text flow. Although I can understand that they can be useful

>     for some and to emphasis its semantic togetherness. I don't like this

>     concept. :)

>

>

>      > Also, your problem, in this case, stems only from a customization ...

>      > and not even a simple subset; you're saying, 'I have a problem if I

>      > choose a subset AND alter the behavior of para'.

>

>     Well, yes, maybe this is not the best sentence. :)

>

>

>      > The fact that there are several cases (I think) where only paras are

>      > allowed inside something else leads me to think that lists-in-paras

>      > is a feature, not a problem, or that it was a design choice. But I'd

>      > love to hear someone with actual historical knowledge pipe up.

>

>     It is a feature and for some people it has a real value.

>

>     Maybe my dislike comes from the fact that writing customization layers

>     in XSLT can be a pain when dealing with such mixed content. If you have

>     paras and other block elements, there is a clear separation.

>

>

>      > On the other hand, perhaps we'd be better off if the model was

>      > simpler and instead of paras, every place where a para is allowed

>      > allowed any block element. Would there be problems with that path, I

>      > wonder? I'd want to review the schema.

>

>     Not sure. Probably, it makes the schema more elaborate. Plus you have

>     to adapt the XSLT stylesheets as well to understand all the

>     combinations -- and deal with unusual combinations appropriately.

>

>     Well, usually DocBook has a very relaxed or broad content modell. I

>     observed the opposite with abstract. Not sure why this is the case,

>     that why I' wondering and wrote this to the list.

>

>

>     --

>     Gruß/Regards,

>          Thomas Schraitle

>

>

>

>

> --

> --------------------------------------

> Aaron DaMommio: Husband, father, writer, juggler, and expert washer of

> dishes.

> - My blog: http://aarondamommio.blogspot.com

> - Need a juggler? http://amazingaaronjuggler.blogspot.com/

> =======================================