Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1axyQD-0004DW-HR for pgsql-docs@arkaria.postgresql.org; Wed, 04 May 2016 15:09:05 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1axyQD-0001EY-45 for pgsql-docs@arkaria.postgresql.org; Wed, 04 May 2016 15:09:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1axyQB-00016n-AO for pgsql-docs@postgresql.org; Wed, 04 May 2016 15:09:03 +0000 Received: from mail-lf0-x22c.google.com ([2a00:1450:4010:c07::22c]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1axyQ8-00024d-D3 for pgsql-docs@postgresql.org; Wed, 04 May 2016 15:09:02 +0000 Received: by mail-lf0-x22c.google.com with SMTP id y84so63970605lfc.0 for ; Wed, 04 May 2016 08:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=IcsvqzV6NAibfCEE+w7/uzY4/2MrdSOYHYV1hmXQSko=; b=ob5FM+twHmaHc2qamsmZq7BqkYOF7Trae0eRjugOWmX2ZFVoVYgQlPm5Q0dWdswIWw Rt9nhkc9+dP8IyIhrZwovFcCRA5Y8MUo0I5RAAFtviCox0fhCoDiXJzSU1EH+4pq+236 23U56fkpfL3ZdqTZ0SRnTa5Og/puIa1s49pkEgZvPTulahRNtc2aWbxrST24iBZBEOEi bee4Kq0QVCBhF1KrOyxHwRu9FRrO73G99pMS6l9fpfz2ciatasbyuF/GLprD+tlPiCGS 6gD4/I/MWd7d3RHr3ZVl/0G7W/TOsQJmbXRlknWDkRVUwlp+ueO7oYJN0UwRTLnoRWaL yAlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=IcsvqzV6NAibfCEE+w7/uzY4/2MrdSOYHYV1hmXQSko=; b=Mg/xdWN2+dFve3wXnZmkB+059Z+HIF3tcJhP72S1Tnwzm6P7y9BnpNbIp+s2/ExuzI A0uStMC+JtsU5K7Eof67VWck+VQJZcC/2CU+PGh6GPWAYFg/2H8i3MqD7kLUTBPC5tfL ied1ydd9XVnKldRPo2nMlJaaKoC7lcRIcue1g4JP8rL8nx2w+YqqWReaLS9I0eJKpUh1 Tgc1IXoOCbLwh7ADXI6kjhGTrlrHYLJXix+3A6GTJ32oVmHEJ8QTsxkmZ0FQBDWQ+XDy IwVw1oiS0yYw6wi+8vauN4M0uO/7TOXgIW0sZvnCXObHfGrKEzn+m7ZlxBhsytfhraZQ XvSQ== X-Gm-Message-State: AOPr4FVHoFzmS07FavAYxOjU1I8toG2e7tPNjPX99p4yofWf75V7Hx6ddDe5k4tTxVx5xg== X-Received: by 10.25.201.129 with SMTP id z123mr3703367lff.140.1462374539820; Wed, 04 May 2016 08:08:59 -0700 (PDT) Received: from [1.0.0.7] ([109.196.196.208]) by smtp.gmail.com with ESMTPSA id rs2sm691851lbb.33.2016.05.04.08.08.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2016 08:08:58 -0700 (PDT) Subject: Re: Docbook 5.x To: =?UTF-8?Q?J=c3=bcrgen_Purtz?= , pgsql-docs@postgresql.org References: <57179283.6080704@purtz.de> <20160503193441.GA61759@alvherre.pgsql> <572A0AD2.2070909@purtz.de> From: Alexander Law Message-ID: <572A1089.7030004@gmail.com> Date: Wed, 4 May 2016 18:08:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <572A0AD2.2070909@purtz.de> Content-Type: multipart/alternative; boundary="------------000204090403060302020909" X-Pg-Spam-Score: 0.6 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org This is a multi-part message in MIME format. --------------000204090403060302020909 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Jürgen, As was stated in the aforementioned thread, solution 2 can be much (8x) faster with some xslt optimizations, but I think now we should outline some roadmap before we start to prepare patches and so. Maybe we should convert to XML with DocBook4 at first step? Then, once we get everything stabilized, we can upgrade to DocBook5. Shouldn't we decompose the conversion procedure, so we could perform fully automatic conversion without any manual changes, and then fix non-valid situations, you described before? And one more question - Is conversion to DocBook5 your final goal? Or maybe you have any further plans regarding documentation, such as translating it to Deutsch? Best regards, Alexander 04.05.2016 17:44, Jürgen Purtz пишет: > Hello, > > I measured following elapsed times on an Intel i5 processor: > > 1. generate all HTML files with dsl script (make html): 0:48 min. > 2. generate all HTML files with xslt script (make xslthtml): 16:01 min. > 3. generate all HTML files with xslt script in the new environment > (pure Docbook5): 4:07 min. > 4. Generating different things via dsl scripts in the new environment > may be possible. But the changelog of the Docbook5 dsl scripts > shows, that the last modification occurred in 2004 - this way is a > dead end. > > There is one principle and a lot of minor differences between 2 and 3. > Solution 2 is based on an xml-file and xslt scripts which are based on > Docbook4. The basic difference to 3 is, that in 3 everything is > Docbook5 compliant: there are only Docbook5 xml- and xslt-files (as my > workflow is: db4 --> xml --> db5 -- (db5 xslt) --> html). The minor > differences concerns the fact, that actually there are errors in my > xml files and that I made only a few parameterisation to the Docbook5 > standard xslt files - no optimization at all. > > I used following tools: perl, xmllint and xsltproc. osx and OpenJade > are obsolete in the new environment (so far, there is much more work > to do). > > Jürgen Purtz > > > > On 03.05.2016 22:13, Oleg Bartunov wrote: >> >> >> On Tue, May 3, 2016 at 10:34 PM, Alvaro Herrera >> wrote: >> >> Jürgen Purtz wrote: >> > Hi, >> > actually we use DocBook V4.2 for the PostgreSQL manuals. I >> suggest an >> > upgrade to DocBook 5.x. This sounds simple, but it will be a >> long process >> > with many sub-tasks. >> >> Yes, agreed. The killer objection placed last time was that it took >> something like 10x longer to generate the HTML using the XML-based >> toolchain than the SGML-based ones. If this is not fixed, let's >> forget >> about this whole thing until it is. So, would you time the process >> using both toolchains and report back? >> >> >> As it stated in >> http://www.postgresql.org/message-id/562E061B.1090809@postgrespro.ru >> the xml performance may be greatly improved. Alexander, what is >> current state of art of your patch ? How slow is xml in compare to sgml ? >> >> >> >> -- >> Álvaro Herrera http://www.2ndQuadrant.com/ >> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >> >> >> -- >> Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-docs >> >> > --------------000204090403060302020909 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hello Jürgen,

As was stated in the aforementioned thread, solution 2 can be much (8x) faster with some xslt optimizations, but I think now we should outline some roadmap before we start to prepare patches and so.
Maybe we should convert to XML with DocBook4 at first step?
Then, once we get everything stabilized, we can upgrade to DocBook5.
Shouldn't we decompose the conversion procedure, so we could perform fully automatic conversion without any manual changes, and then fix non-valid situations, you described before?

And one more question - Is conversion to DocBook5 your final goal? Or maybe you have any further plans regarding documentation, such as translating it to Deutsch?

Best regards,
Alexander


04.05.2016 17:44, Jürgen Purtz пишет:
Hello,

I measured following elapsed times on an Intel i5 processor:
  1. generate all HTML files with dsl script (make html): 0:48 min.
  2. generate all HTML files with xslt script (make xslthtml): 16:01 min.
  3. generate all HTML files with xslt script in the new environment (pure Docbook5): 4:07 min.
  4. Generating different things via dsl scripts in the new environment may be possible. But the changelog of the Docbook5 dsl scripts shows, that the last modification occurred in 2004 - this way is a dead end.
There is one principle and a lot of minor differences between 2 and 3. Solution 2 is based on an xml-file and xslt scripts which are based on Docbook4. The basic difference to 3 is, that in 3 everything is Docbook5 compliant: there are only Docbook5 xml- and xslt-files (as my workflow is: db4 --> xml --> db5 -- (db5 xslt) --> html). The minor differences concerns the fact, that actually there are errors in my xml files and that I made only a few parameterisation to the Docbook5 standard xslt files - no optimization at all.

I used following tools: perl, xmllint and xsltproc. osx and OpenJade are obsolete in the new environment (so far, there is much more work to do).

Jürgen Purtz



On 03.05.2016 22:13, Oleg Bartunov wrote:


On Tue, May 3, 2016 at 10:34 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Jürgen Purtz wrote:
> Hi,
> actually we use DocBook V4.2 for the PostgreSQL manuals. I suggest an
> upgrade to DocBook 5.x. This sounds simple, but it will be a long process
> with many sub-tasks.

Yes, agreed.  The killer objection placed last time was that it took
something like 10x longer to generate the HTML using the XML-based
toolchain than the SGML-based ones.  If this is not fixed, let's forget
about this whole thing until it is.  So, would you time the process
using both toolchains and report back?
the xml performance may be greatly improved. Alexander, what is current state of art of your patch ? How slow is xml in compare to sgml ?
 


--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs



--------------000204090403060302020909--