texinfo: Use @bibcite{ANSI} rather than @xref{Bibliography}

src/doc/new-doc/standards/data_and_control_flow.txi

@@ -146,7 +146,7 @@ ECL is implemented using either a C or a C++ compiler. This is not a limiting fa
 
 The previous conventions set some burden on the C programmer that calls ECL, for she must know the type of function that is being called and supply the right number of arguments. This burden disappears for Common Lisp programmers, though.
 
-As an example let us assume that the user wants to invoke two functions which are part of the ANSI (@xref{Bibliography}) standard and thus are exported with a C name. The first example is cl_cos, which takes just one argument and has a signature @code{cl_object cl_cos(cl_object)}.
+As an example let us assume that the user wants to invoke two functions which are part of the ANSI @bibcite{ANSI} standard and thus are exported with a C name. The first example is cl_cos, which takes just one argument and has a signature @code{cl_object cl_cos(cl_object)}.
 
 @verbatim
 #include <math.h>

src/doc/new-doc/standards/environment.txi

@@ -12,7 +12,7 @@ Display the assembly code of a function
 A symbol which is bound to a function in the global environment, or a lambda form
 @end table
 @subsubheading Description
-As specified in ANSI (@xref{Bibliography}) this function outputs the internal represention of a compiled function, or of a lambda form, as it would look after being compiled.
+As specified in ANSI @bibcite{ANSI} this function outputs the internal represention of a compiled function, or of a lambda form, as it would look after being compiled.
 
 ECL only has a particular difference: it has two different compilers, one based on bytecodes and one based on the C language. The output will thus depend on the arguments and on which compiler is active at the moment in which this function is run.
 

src/doc/new-doc/standards/filenames.txi

@@ -3,7 +3,7 @@
 
 @node Filenames - Syntax
 @subsection Syntax
-A pathname in the file system of Common-Lisp consists of six elements: host, device, directory, name, type and version. Pathnames are read and printed using the @code{#P} reader macro followed by the namestring. A namestring is a string which represents a pathname. The syntax of namestrings for logical pathnames is well explained in the ANSI (@xref{Bibliography}) and it can be roughly summarized as follows:
+A pathname in the file system of Common-Lisp consists of six elements: host, device, directory, name, type and version. Pathnames are read and printed using the @code{#P} reader macro followed by the namestring. A namestring is a string which represents a pathname. The syntax of namestrings for logical pathnames is well explained in the ANSI @bibcite{ANSI} and it can be roughly summarized as follows:
 
 @verbatim
 [hostname:][;][directory-item;]0 or more[name][.type[.version]]

src/doc/new-doc/standards/files.txi

@@ -5,7 +5,7 @@
 @subsection Dictionary
 @subsubsection @code{DIRECTORY}
 
-This function does not have any additional arguments other than the ones described in ANSI (@xref{Bibliography}). To list files and directories, it follows the rules for matching pathnames described in @ref{Filenames - Wild pathnames and matching}. In short, you have the following practical examples:
+This function does not have any additional arguments other than the ones described in ANSI @bibcite{ANSI}. To list files and directories, it follows the rules for matching pathnames described in @ref{Filenames - Wild pathnames and matching}. In short, you have the following practical examples:
 
 @float Table, tab:examples-using-directory
 @caption{Examples of using @code{DIRECTORY}}

src/doc/new-doc/standards/printer.txi

@@ -1,7 +1,7 @@
 @node Printer
 @section Printer
 
-In all situations where the rules are well specified, ECL prints objects according to ANSI (@xref{Bibliography}). The specification leaves however a number of cases as implementation dependent behavior. The output of ECL in those cases is summarized in @ref{tab:impl-spec-print-rep}. Except for the types @code{character} and @code{random-state}, most of those examples regard non-standard written forms @code{#<...>} cannot be read back using @code{read}. These printed representations are just informative and should not be used to reconstruct or compare objects.
+In all situations where the rules are well specified, ECL prints objects according to ANSI @bibcite{ANSI}. The specification leaves however a number of cases as implementation dependent behavior. The output of ECL in those cases is summarized in @ref{tab:impl-spec-print-rep}. Except for the types @code{character} and @code{random-state}, most of those examples regard non-standard written forms @code{#<...>} cannot be read back using @code{read}. These printed representations are just informative and should not be used to reconstruct or compare objects.
 
 @float Table, tab:impl-spec-print-rep
 @caption{Implementation-specific printed representation}

src/doc/new-doc/standards/streams.txi

@@ -6,7 +6,7 @@
 
 @node Streams - Supported types
 @subsubsection Supported types
-ECL implements all stream types described in ANSI (@xref{Bibliography}). Additionally, when configured with option @code{--enable-clos-streams}, ECL includes a version of Gray streams where any object that implements the appropiate methods (@code{stream-input-p}, @code{stream-read-char}, etc) is a valid argument for the functions that expect streams, such as @code{read}, @code{print}, etc.
+ECL implements all stream types described in ANSI @bibcite{ANSI}. Additionally, when configured with option @code{--enable-clos-streams}, ECL includes a version of Gray streams where any object that implements the appropiate methods (@code{stream-input-p}, @code{stream-read-char}, etc) is a valid argument for the functions that expect streams, such as @code{read}, @code{print}, etc.
 
 @node Streams - Element types
 @subsubsection Element types