OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

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


Subject: Canonical DocBook


I agree that "Logically speaking, paragraphs can contain lists and tables (and mathematical formulas and ...)". But some popular Document formats do not support that. ODF has no neutral wrapper for this situation. Not sure about OOXML.
 
This seems to make it quite obvious that the intermediate format must support the possibility of para Elements with included block elements, but that, on the other hand, sometimes special actions must be taken for the subsequent transformation into other formats.
 
If the preprocessing steps would transform paragraphs without block elements into simpara, but leave para with block elements untouched, the difference would be visible, and subsequent steps could apply different templates, if neccessary.
 
Norm, how would an (Relax NG | XSD 1.1) Schema for the outcome of Step 7 differ from the DocBook 5.2 Schema? It is a subset, isn't it?
 
Regards, Frank
 
 
Gesendet: Montag, 28. Februar 2022 um 08:55 Uhr
Von: "Norm Tovey-Walsh" <ndw@nwalsh.com>
An: "Frank Steimke" <f-steimke@berger-und-steimke.de>
Cc: docbook-apps@lists.oasis-open.org
Betreff: Re: [docbook-apps] Canonical DocBook
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


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