Canonical DocBook / para vs simpara

[Frank Steimke <f-steimke@berger-und-steimke.de>]

Yes. If the para element has an xml:id attribute, you will have to decide which of the elements in the generated sequence should get that id. I would vote for the first Element, but every other Element is also possible. A reference to the para element in DocBook references a larger area (namely the one including the block elements) than in the generated document.

On the other hand, an author who for some reason needs to publish his document in an Office format would have to find a solution to this problem anyway. If there is no automatic transformation from DocBook to Office, then just manually.

If no agreement can be reached in a discussion on this aspect, intermediate solutions might help. For example, it would help to transform all para elements that do not contain block elements into simpara elements. This would at least make it clear that the remaining para elements are always those that contain block elements which may require special attention. Their transformation into a sequence of simpara and block elements could be done in the first step in the transformation to ODF.

The benefit would be, that the challenge is clearly documented in the description of the interchange format: "If you see a para element in the output, then you have to take care about the included block elements." Even with para elements allowed, this would help for the development of the transformation into office formats.

It would be interesting to know how many such controversial proposals actually exist. I would also advocate, for example, that the sect1 to sect6 elements should be transformed to section elements.

Probably one should start with a collection of properties for the interchange format (that is, a rough first description of the docbook subset) and match which of them are now already supported by xslTNG steps, or can be achieved very easily?

Regards,
Frank

Am 27.02.22 um 23:23 schrieb David Cramer:

On 2/27/22 1:18 PM, Frank Steimke wrote:

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.

You potentially lose information by doing that. For example, when normalizing, profiling and other attributes on the enclosing table would need to be copied to the paras you create before and after the table or list and onto the table or list itself as well. But doing so might change the author's intent in subtle ways depending on what job those attributes are doing.

I guess this is Norm's point about everybody having a different 80%.

Regards,

David