Canonical DocBook / para vs simpara

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
>