Subject: broken doc

From: Tatsuo Ishii <[email-masked]>
Date: Fri, 02 Mar 2007 14:32:11 +0900 (JST)

CVS HEAD doc won't compile due to broken mark up. Please someone
commit following patches if they are appropreate. 

Also please do not commit broken sgml files without trying to compile
them.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

Index: array.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/array.sgml,v
retrieving revision 1.58
diff -c -r1.58 array.sgml
*** array.sgml	20 Feb 2007 14:54:47 -0000	1.58
--- array.sgml	2 Mar 2007 05:29:24 -0000
***************
*** 243,254 ****
  (1 row)
  </programlisting>
  
    If any dimension is written as a slice, i.e contains a colon, then all
    dimensions are treated as slices.  If a dimension is missing, it is
    assumed to be <literal>[1:1]</>.  If a dimension has only a single
    number (no colon), that dimension is treated as being from <literal>1</>
    to the number specified.  For example, <literal>[2]</> is treated as
!   <literal>[1:2], as in this example:
  
  <programlisting>
  SELECT schedule[1:2][2] FROM sal_emp WHERE name = 'Bill';
--- 243,257 ----
  (1 row)
  </programlisting>
  
+ </para>
+ 
+ <para>
    If any dimension is written as a slice, i.e contains a colon, then all
    dimensions are treated as slices.  If a dimension is missing, it is
    assumed to be <literal>[1:1]</>.  If a dimension has only a single
    number (no colon), that dimension is treated as being from <literal>1</>
    to the number specified.  For example, <literal>[2]</> is treated as
!   <literal>[1:2]</>, as in this example:
  
  <programlisting>
  SELECT schedule[1:2][2] FROM sal_emp WHERE name = 'Bill';
[t-ishii@localhost sgml]$

---

From: Tom Lane <[email-masked]>
Date: Fri, 02 Mar 2007 01:02:41 -0500

> commit following patches if they are appropreate. 

Done.

> Also please do not commit broken sgml files without trying to compile

Some committers are using DocBook installations that seem quite lax
about closing tags :-(, so they fail to see this type of breakage.

			regards, tom lane

---

From: Tatsuo Ishii <[email-masked]>
Date: Fri, 02 Mar 2007 15:06:39 +0900 (JST)

> > commit following patches if they are appropreate. 

Thanks.

> about closing tags :-(, so they fail to see this type of breakage.

Oh, I didn't know that(in my case I'm using Linux packages).
--
Tatsuo Ishii
SRA OSS, Inc. Japan

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 2 Mar 2007 18:34:33 -0500 (EST)

> about closing tags :-(, so they fail to see this type of breakage.

Yep.  What should I upgrade, and to what version?

-- 
  Bruce Momjian  <[email-masked]>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---

From: Tom Lane <[email-masked]>
Date: Fri, 02 Mar 2007 18:43:50 -0500

> Yep.  What should I upgrade, and to what version?

I dunno --- I just use what ships with Fedora.  The relevant FC6
packages seem to be

docbook-dtds-1.0-30
docbook-simple-1.0-2.1
docbook-slides-3.3.1-2.1
docbook-style-dsssl-1.79-4
docbook-style-xsl-1.69.1-5
docbook-utils-0.6.14-5
docbook-utils-pdf-0.6.14-5
linuxdoc-tools-0.9.21-6.2.1

but I've got no idea which of these is the critical factor.

			regards, tom lane

---

From: "Joshua D. Drake" <[email-masked]>
Date: Fri, 02 Mar 2007 15:46:32 -0800

> but I've got no idea which of these is the critical factor.

I am pulling this way out of the back of my head, and Peter might be a
better one to ask but I seem to recall that you can set the closing
bracket requirement in the stylesheet itself.

Joshua D. Drake

> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>                http://archives.postgresql.org
> 

-- 

      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

---

From: Warren Turkal <[email-masked]>
Date: Sat, 3 Mar 2007 00:49:01 -0700

> bracket requirement in the stylesheet itself.

XML should require the closing tag. Is it possible that you are using the SGML 
processor to generate the document instead of the XML processor?

wt
-- 
Warren Turkal (w00t)

---

From: Peter Eisentraut <[email-masked]>
Date: Sat, 3 Mar 2007 10:02:00 +0100

Joshua D. Drake wrote:
> I am pulling this way out of the back of my head, and Peter might be
> a better one to ask but I seem to recall that you can set the closing

That is incorrect.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---

From: Peter Eisentraut <[email-masked]>
Date: Sat, 3 Mar 2007 10:02:25 +0100

Warren Turkal wrote:
> XML should require the closing tag.

But this is not XML.

---

From: "Andrew Dunstan" <[email-masked]>
Date: Sat, 3 Mar 2007 05:49:46 -0600 (CST)

> processor to generate the document instead of the XML processor?

the docs are in SGML ...

cheers

andrew

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 30 Aug 2007 22:04:33 -0400 (EDT)

> bracket requirement in the stylesheet itself.

I figured out how to make my toolchain warn about missing tags like
newer tool chains.  My openjade needs the "-wfully-tagged" warning.  I
added it to sgml/Makefile.

---

From: Tatsuo Ishii <[email-masked]>
Date: Fri, 31 Aug 2007 12:24:17 +0900 (JST)

> added it to sgml/Makefile.

Can someone please fix this?

openjade  -wall -wno-unused-param -wno-empty -wfully-tagged -D . -c /usr/share/sgml/docbook/dsssl-stylesheets/catalog -d stylesheet.dsl -i output-html -t sgml postgres.sgml
openjade:bookindex.sgml:2731:0:E: character data is not allowed here
openjade:bookindex.sgml:2732:66:E: document type does not allow element "ULINK" here; missing one of "SEEIE", "SEEALSOIE", "SECONDARYIE" start-tag
openjade:bookindex.sgml:2744:0:E: character data is not allowed here
openjade:bookindex.sgml:2745:66:E: document type does not allow element "ULINK" here; missing one of "SEEIE", "SEEALSOIE", "SECONDARYIE" start-tag
--
Tatsuo Ishii
SRA OSS, Inc. Japan

---

From: Bruce Momjian <[email-masked]>
Date: Thu, 30 Aug 2007 23:25:57 -0400 (EDT)

> openjade:bookindex.sgml:2745:66:E: document type does not allow element "ULINK" here; missing one of "SEEIE", "SEEALSOIE", "SECONDARYIE" start-tag

Yes, committing a fix now, and asking on docs how to fix it for good.

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 30 Aug 2007 23:36:46 -0400

Tatsuo Ishii wrote
> openjade:bookindex.sgml:2745:66:E: document type does not allow element "ULINK" here; missing one of "SEEIE", "SEEALSOIE", "SECONDARYIE" start-tag

It's working for me

cheers

andrew

---

From: Tatsuo Ishii <[email-masked]>
Date: Fri, 31 Aug 2007 12:46:05 +0900 (JST)

> Yes, committing a fix now, and asking on docs how to fix it for good.

Thanks. Working for me now.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

---

From: Tom Lane <[email-masked]>
Date: Fri, 31 Aug 2007 00:06:12 -0400

> It's working for me

On Fedora Core 6's sgml toolchain, HEAD builds but un-commenting those
two index entries fails, just as Tatsuo says.

I'm no expert in this, but looking at the complained-of bookindex.sgml
entries makes me think that those index entries have a semantic conflict
with these entries over in indices.sgml:

   <indexterm>
    <primary>GiST</primary>
    <see>index</see>
   </indexterm>

   <indexterm>
    <primary>GIN</primary>
    <see>index</see>
   </indexterm>

Perhaps we need to have a meeting of the minds on who gets to define the
primary index entries about GiST and GIN?

Peter will probably have a clearer idea about how to fix this ...

			regards, tom lane

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 31 Aug 2007 11:16:40 +0200

> with these entries over in indices.sgml:

Yeah, apparently it is not supported to have a single term being a "see 
$elsewhere" and a direct link.  The semantics of that are debatable anyway.  
The index building tool just creates garbage in that case.

> primary index entries about GiST and GIN?

I'd say that the text search section shouldn't be the primary source on GiST 
and GIN, just like the section on arithmetic operators isn't the primary 
source on B-tree.  That might require moving some text around, though.