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 <> wrote:
Hi Aron,
On Tue, 3 Feb 2015 10:11:32 -0600
Aaron DaMommio <> 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/
=======================================
