Re: DocBook 5.2

From: Jürgen Purtz <juergen(at)purtz(dot)de>
To: pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: DocBook 5.2
Date: 2022-09-05 14:40:33
Message-ID: 01689f3f-415c-bbd3-7c0f-5373b6c7072b@purtz.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On 05.09.22 14:15, Guillaume Lelarge wrote:
> Le lun. 5 sept. 2022 à 13:14, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> a écrit :
>
> On 2022-Sep-05, Jürgen Purtz wrote:
>
> > - <sect1 id="xtypes">
> > + <sect1 xml:id="xtypes">
> >    <title>User-Defined Types</title>
>
> OK, these seem quite significant changes that are likely to cause
> great
> pain.  So I repeat my question, what are the benefits of making this
> change?  They better be very very substantial.
>
>
> I totally agree with Alvaro.
>
> They will also cause massive pain for translators. There are already
> some changes that were pretty bad for me. For example, when all the
> tables in func.sgml were modified. In v15, I also remember massive
> changes on protocol.sgml. I won't complain if there is a significant
> benefit for readers, which is why I didn't complain for func.sgml even
> if it meant I had to translate it all over again. But if there's a
> massive change over the whole manual for a strictly limited benefit, I
> guess there won't be enough motivation for me to translate it all over
> again.
>
>
> --
> Guillaume.

The goal of the migration is an approximation to today's technology,
especially programming interfaces and standards, to be able to use and
interact with nowadays tools. Of course, this leads to internal
technical changes. It is not intended to change anything at the readers
surface. In that respect, it is comparable with the sgml to xml conversion.

* The introduction of RELAX NG instead of DTDs leads to a much richer
controlling of the sgml files.
* The introduction of namespaces instead of a DOCTYPE definition
offers the possibility to integrate tags of other namespaces into
our documentation, eg.: MathML, XInclude, XLink, ... .
* The changes during the migration consist mainly in a renaming of
tag-names. The most important for us is 'ulink'.

* After the migration the validation is much stricter than before.
Because we have used tags in a more or less 'individual' style,
especially when describing commands, there are a lot of violations
against the RELAX NG schema. Modifications caused by such problems
are those, which will create the most pain - for back-patching as
well as for translators.
* Possibly the pain for translators decreases significantly by using
the same migration scripts on their already translated sgml files.
* I don't understand where the pain for back-patching is when the
attribute 'id' changes to 'xml:id'. It is very unlikely that the id
of a section or another tag will change, or something else in such
lines. In nearly all cases such lines will keep as they are,
back-patching will not be necessary at such places.

What is the alternative to a migration? DocBook 4.5 forever?

--
J. Purtz

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message PG Doc comments form 2022-09-06 08:15:14 pg_dump: regular expression notation for tables
Previous Message Justin Pryzby 2022-09-05 12:23:36 Re: Unclear text at https://www.postgresql.org/docs/14/when-can-parallel-query-be-used.html