Uppercase SGML entity declarations

On Mon, Apr 4, 2011 at 5:11 AM, Gabriele Bartolini
<gabriele.bartolini@2ndquadrant.it> wrote:

 I have made very small modifications to a few files in the documentation
directory, which involve SGML entity declarations. Currently they are all
written lowercase, the patch makes them uppercase. This won't affect SGML
parsing, as SGML is case insensitive - even though it is a good practice to
write SGML declarations in uppercase.

  An example is:

<!entity abort              system "abort.sgml">

  written

<!ENTITY abort              SYSTEM "abort.sgml">

  This patch makes also every single directive of them XML compliant.

Forgive me for asking what may seem like a stupid question, but what's
not XML compliant about them now, and why do we care? The text is
only ever going to parse as SGML (not XML) so I guess I don't see why
it matters. I don't really object to the proposed patch but I guess
I'm not sure what it accomplishes.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Gabriele Bartolini <gabriele.bartolini@2ndQuadrant.it> writes:

I have made very small modifications to a few files in the
documentation directory, which involve SGML entity declarations.
Currently they are all written lowercase, the patch makes them
uppercase. This won't affect SGML parsing, as SGML is case insensitive -
even though it is a good practice to write SGML declarations in uppercase.

What's the point of this exactly? I don't think we'd accept changing
every tag in the documentation to upper case, so why should we change
a small subset of them?

regards, tom lane

Hi Robert (and Tom),

Il 04/04/11 16:57, Robert Haas ha scritto:

Forgive me for asking what may seem like a stupid question, but what's
not XML compliant about them now, and why do we care? The text is
only ever going to parse as SGML (not XML) so I guess I don't see why
it matters. I don't really object to the proposed patch but I guess
I'm not sure what it accomplishes.

My apologies, I should have explained it better and at once.

Here is the context. I am coordinating the Italian translation of the
documentation and we are about to create a branch for 9.1. The
publishing mechanism is based on DocBook XML (as well as the French
one), as we are facing extreme difficulties publishing using SGML tools.

My intention was to start and change some simple documentation files in
order to make our conversion process from SGML to XML smoother, while
keeping the SGML compatibility of the original documentation intact.
Also I was trying to make the ENTITY declarations consistent throughout
the documents.

I hope I gave you a more clear explanation.

Cheers,
Gabriele

--
Gabriele Bartolini - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gabriele.bartolini@2ndQuadrant.it | www.2ndQuadrant.it

Gabriele Bartolini <gabriele.bartolini@2ndQuadrant.it> writes:

My intention was to start and change some simple documentation files in
order to make our conversion process from SGML to XML smoother, while
keeping the SGML compatibility of the original documentation intact.

AFAIK, the main stumbling block for that is that XML doesn't allow
abbreviated close tags (ie, <foo>whatever</>). Which is something that
we are not likely to give up. So I'm not sure of the point of changing
something as trivial as entity declaration casing. You're going to end
up having to fork the documentation anyway, or at least feed it through
an SGML to XML converter. So why not fix the entity casing then?

regards, tom lane

Il 04/04/11 18:37, Tom Lane ha scritto:

AFAIK, the main stumbling block for that is that XML doesn't allow
abbreviated close tags (ie,<foo>whatever</>). Which is something that
we are not likely to give up. So I'm not sure of the point of changing
something as trivial as entity declaration casing. You're going to end
up having to fork the documentation anyway, or at least feed it through
an SGML to XML converter. So why not fix the entity casing then?

We do it. However, given that the files that have been changed are
edited very rarely, the scope of the patch is limited and compatibility
with SGML is kept, I thought changing this at source level would be
something to propose and submit.

Ciao,
Gabriele

--
Gabriele Bartolini - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gabriele.bartolini@2ndQuadrant.it | www.2ndQuadrant.it

On 04.04.2011 18:37, Tom Lane wrote:

AFAIK, the main stumbling block for that is that XML doesn't allow
abbreviated close tags (ie,<foo>whatever</>). Which is something that
we are not likely to give up. So I'm not sure of the point of changing
something as trivial as entity declaration casing. You're going to end
up having to fork the documentation anyway, or at least feed it through
an SGML to XML converter. So why not fix the entity casing then?

Tom,

Honestly, for German I don't mind yet if it is XML or SGML. XML might
be better in future for maintenance tools.

Anyway, I figured out there is another argument for XML:

My information is that DocBook 5.0 won't support SGML anymore.

Which means - sooner or later a reaction is needed.

Susanne
P.S.:
Btw. I change <foo>whatever</> into <foo>whatever</foo> when it
is in the parts which I am translating because my emacs indent don't
like </>.

--
Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com

On Mon, Apr 4, 2011 at 1:26 PM, Susanne Ebrecht <susanne@2ndquadrant.com> wrote:

My information is that DocBook 5.0 won't support SGML anymore.

Which means - sooner or later a reaction is needed.

Ouch.

Even if that doesn't turn out to be the case, this is pretty harmless,
so maybe we should just apply it and move on.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:

Even if that doesn't turn out to be the case, this is pretty harmless,
so maybe we should just apply it and move on.

I have no great objection to the patch as such; just wondering what the
roadmap is.

regards, tom lane

On Mon, Apr 4, 2011 at 2:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

Even if that doesn't turn out to be the case, this is pretty harmless,
so maybe we should just apply it and move on.

I have no great objection to the patch as such; just wondering what the
roadmap is.

Me, too.

On a practical level, if we're going to do this, shouldn't we also do
!entity -> !ENTITY in Solution.pm?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Apr 4, 2011 at 1:26 PM, Susanne Ebrecht <susanne@2ndquadrant.com> wrote:

Anyway, I figured out there is another argument for XML:

My information is that DocBook 5.0 won't support SGML anymore.

Which means - sooner or later a reaction is needed.

Yes, indeed.

I don't think that during the 9.1 alpha phase is the right time to
think about this, but this certainly seems appropriate to consider as
a 9.2 "ToDo" item.

There are arguments as to why to switch to version 5, which is,
indeed, XML-only.
http://www.docbook.org/tdg5/en/html/ch01.html#introduction-why-to-switch

They argue that version 5
- Is what will get fixes. Which may not matter to us, as I don't
think we have been getting bitten by "horrible DocBook problems."
- Has new functionality. Which may not matter, as we're doubtless not
using all of the functionality of elder versions of DocBook either.
- Is more extensible. Which I imagine doesn't matter, as we weren't
extending earlier versions.
- Is easier to customize. Almost anything would be better than
DSSSL... (http://www.biglist.com/lists/dssslist/archives/200005/msg00120.html
is my little contribution that apparently got used a fair bit by
people)

There is also a possible counter-position to be taken, namely that the
existing tooling works, is mature, and isn't too likely to disappear
in any sort of short term.

In any case, the ToDo shouldn't be about how to convert the SGML to
XML - that's merely one of the tasks. There is already a ToDo item,
which points here:
<http://archives.postgresql.org/pgsql-docs/2006-12/msg00152.php&gt;

It needs to cover making sure such things as that:
a) The output forms presently used (e.g. - PDF, man pages, perhaps
.chm/.rtf) continue to be available
b) We can clearly document what new toolchain is needed to process the
various output forms, and validate that it's sufficiently free,
sufficiently robust, sufficiently portable, and so forth.
c) Integrating the toolchain into the Postgres build process.

This represents a fair bit of work, so it's a bit of a presumption
that it's a wise move to do this in 9.2. I don't think the benefits
that the DocBook folk present for moving to v5 are necessarily
compelling to the Postgres community.

BTW, I wear most of the "DocBook hat" for the Slony project, and I
don't see it being valuable to us ("Slony project") to migrate to v5.
It would require quite a bit of work, and I don't see any of the
claimed benefits being helpful to the "Slony us."
--
http://linuxfinances.info/info/linuxdistributions.html

On Mon, Apr 4, 2011 at 2:50 PM, Christopher Browne <cbbrowne@gmail.com> wrote:

On Mon, Apr 4, 2011 at 1:26 PM, Susanne Ebrecht <susanne@2ndquadrant.com> wrote:

Anyway, I figured out there is another argument for XML:

My information is that DocBook 5.0 won't support SGML anymore.

Which means - sooner or later a reaction is needed.

Yes, indeed.

I don't think that during the 9.1 alpha phase is the right time to
think about this, but this certainly seems appropriate to consider as
a 9.2 "ToDo" item.

There are arguments as to why to switch to version 5, which is,
indeed, XML-only.
http://www.docbook.org/tdg5/en/html/ch01.html#introduction-why-to-switch

AFAICT, the biggest problem with our existing toolchain is that it's
hard for some people to get it working. In theory, we have
documentation that explains this:

http://www.postgresql.org/docs/current/static/docguide-toolsets.html

However, in contrast to the vast majority of our documentation, it stinks.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:

On Mon, Apr 4, 2011 at 2:50 PM, Christopher Browne <cbbrowne@gmail.com> wrote:

There are arguments as to why to switch to version 5, which is,
indeed, XML-only.
http://www.docbook.org/tdg5/en/html/ch01.html#introduction-why-to-switch

AFAICT, the biggest problem with our existing toolchain is that it's
hard for some people to get it working.

Indeed. One thing I'd like to know is whether docbook v5 is any more
portable/easier to install.

regards, tom lane

On 4/4/11, Robert Haas <robertmhaas@gmail.com> wrote:

On Mon, Apr 4, 2011 at 2:50 PM, Christopher Browne <cbbrowne@gmail.com>
wrote:

On Mon, Apr 4, 2011 at 1:26 PM, Susanne Ebrecht <susanne@2ndquadrant.com>
wrote:

Anyway, I figured out there is another argument for XML:

My information is that DocBook 5.0 won't support SGML anymore.

Which means - sooner or later a reaction is needed.

Yes, indeed.

I don't think that during the 9.1 alpha phase is the right time to
think about this, but this certainly seems appropriate to consider as
a 9.2 "ToDo" item.

There are arguments as to why to switch to version 5, which is,
indeed, XML-only.
http://www.docbook.org/tdg5/en/html/ch01.html#introduction-why-to-switch

AFAICT, the biggest problem with our existing toolchain is that it's
hard for some people to get it working. In theory, we have
documentation that explains this:

http://www.postgresql.org/docs/current/static/docguide-toolsets.html

However, in contrast to the vast majority of our documentation, it stinks.

I've certainly wasted non-trivial amounts of time trying to get it to
work on some platforms. I'd be *very* glad to see us using a
simplified toolchain if possible.

Another point to note is that whilst it will still be possible to
install older versions of docbook for a while, presumably that'll
become more and more of a pain, as distros update to 5.x, requiring
users to start building manually, and having to deal with parallel
installations of two versions.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 04.04.2011 21:08, Tom Lane wrote:

Indeed. One thing I'd like to know is whether docbook v5 is any more
portable/easier to install

Unfortunately, as far as I know - there isn't a huge difference.

regards,

Susanne

--
Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com

Excerpts from Gabriele Bartolini's message of lun abr 04 13:18:21 -0400 2011:

Il 04/04/11 18:37, Tom Lane ha scritto:

AFAIK, the main stumbling block for that is that XML doesn't allow
abbreviated close tags (ie,<foo>whatever</>). Which is something that
we are not likely to give up. So I'm not sure of the point of changing
something as trivial as entity declaration casing. You're going to end
up having to fork the documentation anyway, or at least feed it through
an SGML to XML converter. So why not fix the entity casing then?

We do it. However, given that the files that have been changed are
edited very rarely, the scope of the patch is limited and compatibility
with SGML is kept, I thought changing this at source level would be
something to propose and submit.

Given the lack of objections, I have pushed this patch. Thanks.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Mon, Apr 4, 2011 at 4:15 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:

Excerpts from Gabriele Bartolini's message of lun abr 04 13:18:21 -0400 2011:

Il 04/04/11 18:37, Tom Lane ha scritto:

AFAIK, the main stumbling block for that is that XML doesn't allow
abbreviated close tags (ie,<foo>whatever</>).  Which is something that
we are not likely to give up.  So I'm not sure of the point of changing
something as trivial as entity declaration casing.  You're going to end
up having to fork the documentation anyway, or at least feed it through
an SGML to XML converter.  So why not fix the entity casing then?

We do it. However, given that the files that have been changed are
edited very rarely, the scope of the patch is limited and compatibility
with SGML is kept, I thought changing this at source level would be
something to propose and submit.

Given the lack of objections, I have pushed this patch.  Thanks.

I think you still need to update Solution.pm to match.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Excerpts from Robert Haas's message of lun abr 04 16:26:07 -0400 2011:

On Mon, Apr 4, 2011 at 4:15 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:

Excerpts from Gabriele Bartolini's message of lun abr 04 13:18:21 -0400 2011:

Il 04/04/11 18:37, Tom Lane ha scritto:

AFAIK, the main stumbling block for that is that XML doesn't allow
abbreviated close tags (ie,<foo>whatever</>).  Which is something that
we are not likely to give up.  So I'm not sure of the point of changing
something as trivial as entity declaration casing.  You're going to end
up having to fork the documentation anyway, or at least feed it through
an SGML to XML converter.  So why not fix the entity casing then?

We do it. However, given that the files that have been changed are
edited very rarely, the scope of the patch is limited and compatibility
with SGML is kept, I thought changing this at source level would be
something to propose and submit.

Given the lack of objections, I have pushed this patch.  Thanks.

I think you still need to update Solution.pm to match.

Oops, sorry, done.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Il 04/04/11 22:26, Robert Haas ha scritto:

I think you still need to update Solution.pm to match.

Here it is, including change of 3 'Id' attributes (I made them lowercase).

Thanks,
Gabriele

--
Gabriele Bartolini - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gabriele.bartolini@2ndQuadrant.it | www.2ndQuadrant.it

On mån, 2011-04-04 at 15:02 -0400, Robert Haas wrote:

AFAICT, the biggest problem with our existing toolchain is that it's
hard for some people to get it working. In theory, we have
documentation that explains this:

http://www.postgresql.org/docs/current/static/docguide-toolsets.html

However, in contrast to the vast majority of our documentation, it
stinks.

Umm, if you look under "Debian Packages", there is a one-line command to
execute, which, as far as I can tell, is pretty much guaranteed to get
you going. If that doesn't apply to the OS you are working, then either

a) You haven't contributed better installation documentation, or

b) The makers of your OS haven't bothered to package it properly.

No other toolchain will make that principle easier.