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 <[email protected]> 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. > > [email protected] | +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 <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi Aron, > > > > On Tue, 3 Feb 2015 10:11:32 -0600 > > Aaron DaMommio <[email protected] <mailto:[email protected]>> > 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/ > > ======================================= >
