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