Re: [docbook-apps] Canonical DocBook

[Norm Tovey-Walsh <ndw@nwalsh.com>]

Frank Steimke <f-steimke@berger-und-steimke.de> writes:

> Thank you very much for your comments and suggestions, Norm. Please allow a few remarks.
>
> "After a while, this starts to feel less like a canonical DocBook and
> more like a structural interchange format".
>
> Yes, based on DocBook. After all, the result of standard steps 1 to 7
> is almost a valid DocBook Document, isn't it? That is, with the
> exception of a few additional attributes in a separate namespace (e.
> g. ghost attributes in tables). But it's true that this format is not
> intended for authors. They keep writing the way they do today, and the
> interchange format is generated by applying the xslTNG steps.

For clarity, the output of step 7 in my list is still absolutely valid
DocBook. The ghost elements and ghost attributes technique (that turns
up in both tables and callouts) are purely transitory forms used in
formatting. I was just observing that you might want an even more
normalized intermediate formatâ

> No block Elements within para
>
> That's in my 80% because neither ODF nor OOXML do allow tables or
> lists in paragraphs. I would see a great benefit when the DocBook
> based structural interchange format would allow easy transformation
> into office Standards, especially ODF.

HTML doesnât allow it either, which is why Iâve mostly trained myself
not to do it. But it irritates me on a regular basis:

<para>As you can see:
<orderedlist>
<listitem>
<para>Logically speaking, paragraphs can contain lists and tables.
</para>
</listitem>
<orderedlist>
<listitem>
<para>Making âAs you can see:â as separate paragraph is just wrong.
It isnât even a complete sentence!
</para>
</listitem>
<listitem>
<para>The same is true of what follows.
</para>
</listitem>
</orderedlist>
demonstrating that this paragraph logically contains the preceding
list.</para>

Nothing we can do about formats that donât allow it though. Out of
curiosity, ODF and OOXML have any kind of neutral wrapper that can
contain them, like HTMLâs div?

As David pointed out in another follow-up, unwrapping that structure
changes what an xml:id on the paragraph would identify. Not such a big
deal for linking into a document, but potentially catastrophic for
XInclude or transclusion.

                                        Be seeing you,
                                          norm

--
Norman Tovey-Walsh <ndw@nwalsh.com>
https://nwalsh.com/

> There is only one difference between a madman and me. I am not
> mad.--Salvador Dali

Attachment: signature.asc
Description: PGP signature