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