Lots of duplicate code in docbook

[Thibaut Cuvelier]

On Wed, 30 Mar 2022 at 07:29, Daniel <xracoonx at gmx.de> wrote:

> On 2022-03-28 18:49, Thibaut Cuvelier wrote:
> > On Mon, 21 Mar 2022 at 13:11, Lorenzo Bertini
> > <lorenzobertini97 at gmail.com <mailto:lorenzobertini97 at gmail.com>> wrote:
> >
> >     Il 21/03/22 11:49, Daniel ha scritto:
> >      > On 2022-03-21 10:55, Lorenzo Bertini wrote:
> >      >> There is some degree of duplication between Docbook and LyXHTML
> >     code.
> >      >> I think its because the latter is much older and Thibaut had to
> >     write
> >      >> its own to produce Docbook. This has been brought up also when
> >      >> addressing MathML production. I agree LyX needs more standard XML
> >      >> generating functions.
> >      >>
> >      >> Its part of a larger theme about XML production, and there was a
> >     talk
> >      >> sometime ago about using a library for this.
> >      >
> >      > I might be misunderstanding your comment. But actually, I wanted
> to
> >      > point not to the way XML is generated but more to the actual
> >     content,
> >      > for example, the specific attributes of an element which seem to
> be
> >      > duplicated. But maybe that problem is somehow dependent on the
> >     general
> >      > generation of XML?
> >
> >     Sorry, I meant that code duplication is probably due to the different
> >     maintainers for the two formats and the fact that one is much older
> and
> >     has been untouched for a long (LyXHTML). I remember Thibaut saying he
> >     branched from LyXHTML knowingly, even if it would have meant
> rewriting
> >     some stuff. Looking at your examples, this might be the case.
> >
> >     I think a common interface to write XML elements like tables, tags,
> >     etc,
> >     would help reduce this, but it will be a lot of effort. I'll wait for
> >     Thibaut and Richard to chime in on this.
> >
> >
> > There is already a generic interface for XML tags (but not
> > tree-oriented, like almost all XML tools). However, it does not make
> > sense to have a generic function for a table: CALS and HTML are two
> > quite different formats; moreover, HTML tables in DocBook do not always
> > exactly match what HTML allows (mostly, HTML allows CSS, but DocBook
> > forbids formatting).
>
> Okay. As I said, I have no knowledge about DocBook. I was working on
> adding support for line styles to LyXHTML and noticed that it felt
> strange to work with the code when very similar code appeared in the
> DocBook section.
>
> DocBook does not support CSS Styles?  Well, at least what I added does
> not need to be duplicated for DocBook then. But what is
>
> style
>
>      This attribute specifies style information for the current element.
>
> (https://tdg.docbook.org/tdg/5.0/html.td.html)?
>

You're right, td has a style attribute (it's quite exceptional in DocBook).

I've merged a lot of code between HTML and DocBook for lines in the last
three commits (c7896cf9, ec016162, 0ba1b68f). The codes for DocBook and
XHTML are harder to merge, I believe it's more open to discussion, hence
I'm attaching a patch to this email to gather feedback. I could go further,
but the main codes (::docbook and ::xhtml) differ more in their preamble,
I'd rather do that in a second step, after having some feedback for the
first one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20220401/49c58e18/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-XHTML-DocBook-merge-code-paths-to-generate-a-row-in-.patch
Type: application/octet-stream
Size: 9287 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20220401/49c58e18/attachment-0001.obj>