Re: DocBook 5.2 - Mailing list pgsql-docs

Le lun. 5 sept. 2022 à 13:14, Alvaro Herrera <alvherre@alvh.no-ip.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