Merge branch 'lars/remove-corba-applications/OTP-14283'

* lars/remove-corba-applications/OTP-14283:
  Move the corba applcations to separate repository

88 files changed, 0 insertions, 10814 deletions

diff --git a/lib/orber/doc/etc/.gitignore b/lib/orber/doc/etc/.gitignore
deleted file mode 100644
index e69de29bb2..0000000000
--- a/lib/orber/doc/etc/.gitignore
+++ /dev/null
diff --git a/lib/orber/doc/html/.gitignore b/lib/orber/doc/html/.gitignore
deleted file mode 100644
index e69de29bb2..0000000000
--- a/lib/orber/doc/html/.gitignore
+++ /dev/null
diff --git a/lib/orber/doc/javadoc/.gitignore b/lib/orber/doc/javadoc/.gitignore
deleted file mode 100644
index e69de29bb2..0000000000
--- a/lib/orber/doc/javadoc/.gitignore
+++ /dev/null
diff --git a/lib/orber/doc/man1/.gitignore b/lib/orber/doc/man1/.gitignore
deleted file mode 100644
index e69de29bb2..0000000000
--- a/lib/orber/doc/man1/.gitignore
+++ /dev/null
diff --git a/lib/orber/doc/man3/.gitignore b/lib/orber/doc/man3/.gitignore
deleted file mode 100644
index e69de29bb2..0000000000
--- a/lib/orber/doc/man3/.gitignore
+++ /dev/null
diff --git a/lib/orber/doc/pdf/.gitignore b/lib/orber/doc/pdf/.gitignore
deleted file mode 100644
index e69de29bb2..0000000000
--- a/lib/orber/doc/pdf/.gitignore
+++ /dev/null
diff --git a/lib/orber/doc/src/CosNaming.xml b/lib/orber/doc/src/CosNaming.xml
deleted file mode 100644
index 251e721df1..0000000000
--- a/lib/orber/doc/src/CosNaming.xml
+++ /dev/null
@@ -1,71 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>1997</year><year>2017</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-
-    </legalnotice>
-
-    <title>CosNaming</title>
-    <prepared></prepared>
-    <docno></docno>
-    <checked></checked>
-    <date>1997-06-10</date>
-    <rev>A</rev>
-  </header>
-  <module>CosNaming</module>
-  <modulesummary>The CosNaming service is a collection of interfaces that together define the naming service.</modulesummary>
-  <description>
-    <p>The naming service provides  the principal mechanism for clients to find 
-      objects in an ORB based world. The naming service provides an initial naming
-      context that functions as the root context for all names. Given this context 
-      clients can navigate in the name space. </p>
-    <p>Types that are declared on the CosNaming level are:</p>
-    <code type="none"><![CDATA[
-typedef string Istring;
-struct NameComponent {
-      Istring id;  
-      Istring kind;
-};
-  
-typedef sequence <NameComponent> Name;
-  
-enum BindingType {nobject, ncontext};
-  
-struct Binding {
-      Name    binding_name;
-      BindingType binding_type;
-};
-
-typedef sequence <Binding> BindingList;
-    ]]></code>
-    <p>To get access to the record definitions for the structs use:</p>
-    <code>-include_lib("orber/COSS/CosNaming.hrl").</code>
-    <p>Names are not an ORB object but the can be structured in components as seen by 
-      the definition above. There are no requirements on names so the service can support 
-      many different conventions and standards.</p>
-    <p>There are two different interfaces supported in the service:</p>
-    <list type="bulleted">
-      <item>NamingContext</item>
-      <item>BindingIterator</item>
-    </list>
-  </description>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/CosNaming_BindingIterator.xml b/lib/orber/doc/src/CosNaming_BindingIterator.xml
deleted file mode 100644
index 69b0f42b22..0000000000
--- a/lib/orber/doc/src/CosNaming_BindingIterator.xml
+++ /dev/null
@@ -1,99 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>1997</year>
-      <year>2016</year>
-      <holder>Ericsson AB, All Rights Reserved</holder>
-    </copyright>
-    <legalnotice>
-  Licensed under the Apache License, Version 2.0 (the "License");
-  you may not use this file except in compliance with the License.
-  You may obtain a copy of the License at
- 
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
-
-  The Initial Developer of the Original Code is Ericsson AB.
-    </legalnotice>
-
-    <title>CosNaming_BindingIterator</title>
-    <prepared></prepared>
-    <docno></docno>
-    <checked></checked>
-    <date>1997-06-10</date>
-    <rev>A</rev>
-  </header>
-  <module>CosNaming_BindingIterator</module>
-  <modulesummary>This interface supports iteration over a name binding list.</modulesummary>
-  <description>
-    <p>This interface allows a client to iterate over the Bindinglist it has been
-      initiated with.</p>
-    <p>The type <c>NameComponent</c> used below is defined as:</p>
-    <code type="none">
-      -record('CosNaming_NameComponent', {id, kind=""}).
-    </code>
-    <p><c>id</c> and <c>kind</c> are strings. </p>
-    <p>The type <c>Binding</c> used below is defined as:</p>
-    <code type="none">
-      -record('CosNaming_Binding', {binding_name, binding_type}).
-    </code>
-    <p><c>binding_name</c> is a <c>Name = [NameComponent]</c> and
-      <c>binding_type</c> is an enum which 
-      has the values <c>nobject</c> and <c>ncontext</c>.</p>
-    <p>Both these records are defined in the file <c>CosNaming.hrl</c> and it 
-      is included with:</p>
-    <code type="none">
-      -include_lib("orber/COSS/CosNaming/CosNaming.hrl").
-    </code>
-  </description>
-  <funcs>
-    <func>
-      <name>next_one(BindinIterator) -> Return</name>
-      <fsummary>Return a binding</fsummary>
-      <type>
-        <v>BindingIterator = #objref</v>
-        <v>Return = {bool(), Binding}</v>
-      </type>
-      <desc>
-        <p>This operation returns the next binding and a boolean. The latter
-          is set to true if the binding is valid otherwise false. If the boolean
-          is false there are no more bindings to retrieve.</p>
-      </desc>
-    </func>
-    <func>
-      <name>next_n(BindinIterator, HowMany) -> Return</name>
-      <fsummary>Return a binding list</fsummary>
-      <type>
-        <v>BindingIterator = #objref</v>
-        <v>HowMany = int()</v>
-        <v>BindingList = [Binding]</v>
-        <v>Return = {bool(), BindingList}</v>
-      </type>
-      <desc>
-        <p>This operation returns a binding list with at most HowMany bindings.
-          If there are no more bindings it returns false otherwise true.</p>
-      </desc>
-    </func>
-    <func>
-      <name>destroy(BindingIterator) -> Return</name>
-      <fsummary>Destroy the iterator object</fsummary>
-      <type>
-        <v>BindingIterator = #objref</v>
-        <v>Return = ok</v>
-      </type>
-      <desc>
-        <p>This operation destroys the binding iterator.</p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/CosNaming_NamingContext.xml b/lib/orber/doc/src/CosNaming_NamingContext.xml
deleted file mode 100644
index 4c83e6a240..0000000000
--- a/lib/orber/doc/src/CosNaming_NamingContext.xml
+++ /dev/null
@@ -1,243 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>1997</year><year>2017</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>CosNaming_NamingContext</title>
-    <prepared></prepared>
-    <docno></docno>
-    <checked></checked>
-    <date>1997-06-10</date>
-    <rev>A</rev>
-  </header>
-  <module>CosNaming_NamingContext</module>
-  <modulesummary>This interface supports different bind and access functions for names in a context.</modulesummary>
-  <description>
-    <p>This is the object that defines name scopes, names must be unique within a 
-      naming context. Objects may have multiple names and may exist in multiple
-      naming contexts. Name context may be named in other contexts and cycles are
-      permitted.</p>
-    <p>The type <c>NameComponent</c> used below is defined as:</p>
-    <code type="erl">-record('CosNaming_NameComponent', {id, kind=""}).</code>
-    <p>where <c>id</c> and <c>kind</c> are strings. </p>
-    <p>The type <c>Binding</c> used below is defined as:</p>
-    <code type="erl">-record('CosNaming_Binding', {binding_name, binding_type}).</code>
-    <p>where <c>binding_name</c> is a Name and <c>binding_type</c> is an enum which 
-      has the values <c>nobject</c> and <c>ncontext</c>.</p>
-    <p>Both these records are defined in the file <c>CosNaming.hrl</c> and it 
-      is included with:</p>
-    <code type="erl">-include_lib("orber/COSS/CosNaming/CosNaming.hrl").</code>
-    <p>There are a number of exceptions that can be returned from functions in this 
-      interface.</p>
-    <list type="bulleted">
-      <item>
-        <p>NotFound is defined as </p>
-        <code type="erl">
--record('CosNaming_NamingContext_NotFound',
-        {rest_of_name, why}).</code>
-      </item>
-      <item>
-        <p>CannotProceed is defined as </p>
-        <code type="erl">
--record('CosNaming_NamingContext_CannotProceed',
-        {rest_of_name, cxt}).
-	</code>
-      </item>
-      <item>
-        <p>InvalidName is defined as </p>
-        <code type="erl">
--record('CosNaming_NamingContext_InvalidName', {}).
-	</code>
-      </item>
-      <item>
-        <p>NotFound is defined as </p>
-        <code type="erl">-record('CosNaming_NamingContext_NotFound', {}).</code>
-      </item>
-      <item>
-        <p>AlreadyBound is defined as </p>
-        <code type="erl">-record('CosNaming_NamingContext_AlreadyBound', {}).</code>
-      </item>
-      <item>
-        <p>NotEmpty is defined as </p>
-        <code type="erl">-record('CosNaming_NamingContext_NotEmpty', {}).</code>
-      </item>
-    </list>
-    <p>These exceptions are defined in the file <c>CosNaming_NamingContext.hrl</c> and it 
-      is included with:</p>
-    <code type="erl">
--include_lib("orber/COSS/CosNaming/CosNaming_NamingContext.hrl").
-    </code>
-  </description>
-  <funcs>
-    <func>
-      <name>bind(NamingContext, Name, Object) -> Return</name>
-      <fsummary>Bind a Name to an Object</fsummary>
-      <type>
-        <v>NameContext = #objref</v>
-        <v>Name = [NameComponent]</v>
-        <v>Object = #objref</v>
-        <v>Return = ok</v>
-      </type>
-      <desc>
-        <p>Creates a binding of a name and an object in the naming context. 
-          Naming contexts that are bound using <em>bind()</em> do not participate
-          in name resolution.</p>
-      </desc>
-    </func>
-    <func>
-      <name>rebind(NamingContext, Name, Object) -> Return</name>
-      <fsummary>Bind an Object to the Name even if the Name already is bound</fsummary>
-      <type>
-        <v>NamingContext = #objref</v>
-        <v>Name = [NameComponent]</v>
-        <v>Object = #objref</v>
-        <v>Return = ok</v>
-      </type>
-      <desc>
-        <p>Creates a binding of a name and an object in the naming context even
-          if the name is already bound. Naming contexts that are bound using
-          <em>rebind()</em> do not participate in name resolution.</p>
-      </desc>
-    </func>
-    <func>
-      <name>bind_context(NamingContext1, Name, NamingContex2) -> Return</name>
-      <fsummary>Bind a Name to an NamingContext</fsummary>
-      <type>
-        <v>NamingContext1 = NamingContext2 =#objref</v>
-        <v>Name = [NameComponent]</v>
-        <v>Return = ok</v>
-      </type>
-      <desc>
-        <p>The bind_context function creates a binding of a name and a naming context in
-          the current context.
-          Naming contexts that are bound using <em>bind_context()</em> participate
-          in name resolution.</p>
-      </desc>
-    </func>
-    <func>
-      <name>rebind_context(NamingContext1, Name, NamingContex2) -> Return</name>
-      <fsummary>Bind an NamingContext to the Name even if the Name already is bound</fsummary>
-      <type>
-        <v>NamingContext1 = NamingContext2 =#objref</v>
-        <v>Name = [NameComponent]</v>
-        <v>Return = ok</v>
-      </type>
-      <desc>
-        <p>The rebind_context function creates a binding of a name and a naming context in
-          the current context even if the name already is bound.
-          Naming contexts that are bound using <em>rebind_context()</em> participate
-          in name resolution.</p>
-      </desc>
-    </func>
-    <func>
-      <name>resolve(NamingContext, Name) -> Return</name>
-      <fsummary>Retrieve an Object bound to Name</fsummary>
-      <type>
-        <v>NamingContext = #objref</v>
-        <v>Name = [NameComponent]</v>
-        <v>Return = Object</v>
-        <v>Object = #objref</v>
-      </type>
-      <desc>
-        <p>The resolve function is the way to retrieve an object bound to a name in
-          the naming context. The given name must match exactly the bound name. The 
-          type of the object is not returned, clients are responsible for narrowing 
-          the object to the correct type.</p>
-      </desc>
-    </func>
-    <func>
-      <name>unbind(NamingContext, Name) -> Return</name>
-      <fsummary>Remove the binding for a Name</fsummary>
-      <type>
-        <v>NamingContext = #objref</v>
-        <v>Name = [NameComponent]</v>
-        <v>Return = ok</v>
-      </type>
-      <desc>
-        <p>The unbind operation removes a name binding from the naming context.</p>
-      </desc>
-    </func>
-    <func>
-      <name>new_context(NamingContext) -> Return</name>
-      <fsummary>Create a new NamingContext</fsummary>
-      <type>
-        <v>NamingContext = #objref</v>
-        <v>Return = #objref</v>
-      </type>
-      <desc>
-        <p>The new_context operation creates a new naming context.</p>
-      </desc>
-    </func>
-    <func>
-      <name>bind_new_context(NamingContext, Name) -> Return</name>
-      <fsummary>Create a new NamingContext and bind it to a Name</fsummary>
-      <type>
-        <v>NamingContext = #objref</v>
-        <v>Name = [NameComponent]</v>
-        <v>Return = #objref</v>
-      </type>
-      <desc>
-        <p>The new_context operation creates a new naming context and binds it to
-          Name in the current context.</p>
-      </desc>
-    </func>
-    <func>
-      <name>destroy(NamingContext) -> Return</name>
-      <fsummary>Destroy a NamingContext</fsummary>
-      <type>
-        <v>NamingContext = #objref</v>
-        <v>Return = ok</v>
-      </type>
-      <desc>
-        <p>The destroy operation disposes the NamingContext object and removes it from the 
-          name server. The context must be empty e.g. not contain any bindings to be 
-          removed.</p>
-      </desc>
-    </func>
-    <func>
-      <name>list(NamingContext, HowMany) -> Return</name>
-      <fsummary>List returns a all bindings in the context</fsummary>
-      <type>
-        <v>NamingContext = #objref</v>
-        <v>HowMany = int()</v>
-        <v>Return = {ok, BindingList, BindingIterator}</v>
-        <v>BindingList = [Binding]</v>
-        <v>BindingIterator = #objref</v>
-      </type>
-      <desc>
-        <p>The list operation returns a BindingList with a number of bindings up-to
-          HowMany from the context. It also returns a BindinIterator which can be used to
-          step through the list. If the total number of existing bindings are less
-          than, or equal to, the <c>HowMany</c> parameter a NIL object reference
-          is returned.</p>
-        <p></p>
-        <note>
-          <p>One must destroy the BindingIterator, unless it is a NIL object
-            reference, by using 'BindingIterator':destroy(). Otherwise one can get
-            dangling objects.</p>
-        </note>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/CosNaming_NamingContextExt.xml b/lib/orber/doc/src/CosNaming_NamingContextExt.xml
deleted file mode 100644
index 2af3deadda..0000000000
--- a/lib/orber/doc/src/CosNaming_NamingContextExt.xml
+++ /dev/null
@@ -1,102 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>2000</year><year>2017</year>
-      <holder>Ericsson AB, All Rights Reserved</holder>
-    </copyright>
-    <legalnotice>
-  Licensed under the Apache License, Version 2.0 (the "License");
-  you may not use this file except in compliance with the License.
-  You may obtain a copy of the License at
- 
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
-
-  The Initial Developer of the Original Code is Ericsson AB.
-    </legalnotice>
-
-    <title>CosNaming_NamingContextExt</title>
-    <prepared></prepared>
-    <docno></docno>
-    <checked></checked>
-    <date>2000-08-16</date>
-    <rev>A</rev>
-  </header>
-  <module>CosNaming_NamingContextExt</module>
-  <modulesummary>This interface contains operation for converting a Name sequence to a string and back.</modulesummary>
-  <description>
-    <p>To get access to the record definitions for the structures use:      <br></br>
-</p>
-    <code type="erl">
--include_lib("orber/COSS/CosNaming/CosNaming.hrl").
-    </code>
-    <p>This module also exports the functions described in:</p>
-    <list type="bulleted">
-      <item>
-        <p><seealso marker="CosNaming_NamingContext">CosNaming_NamingContext</seealso></p>
-      </item>
-    </list>
-  </description>
-  <funcs>
-    <func>
-      <name>to_string(NamingContext, Name) -> Return</name>
-      <fsummary>Stringify a <c>Name</c>sequence to a string</fsummary>
-      <type>
-        <v>NameContext = #objref</v>
-        <v>Name = [NameComponent]</v>
-        <v>Return = string() | {'EXCEPTION', NamingContext::InvalidName{}}</v>
-      </type>
-      <desc>
-        <p>Stringifies a <c>Name</c> sequence to a string.</p>
-      </desc>
-    </func>
-    <func>
-      <name>to_name(NamingContext, NameString) -> Return</name>
-      <fsummary>Convert a stringified <c>Name</c>to a <c>Name</c>sequence</fsummary>
-      <type>
-        <v>NameContext = #objref</v>
-        <v>NameString = string()</v>
-        <v>Return = [NameComponent] | {'EXCEPTION', NamingContext::InvalidName{}}</v>
-      </type>
-      <desc>
-        <p>Converts a stringified <c>Name</c> to a <c>Name</c> sequence.</p>
-      </desc>
-    </func>
-    <func>
-      <name>to_url(NamingContext, AddressString, NameString) -> Return</name>
-      <fsummary>Return an URL string constructed from the given Address and Name strings</fsummary>
-      <type>
-        <v>NameContext = #objref</v>
-        <v>Address = NameString = string()</v>
-        <v>Return =  URLString |  {'EXCEPTION', NamingContext::InvalidName{}} |  {'EXCEPTION', NamingContextExt::InvalidAddress{}}</v>
-      </type>
-      <desc>
-        <p>This operation takes a <c>corbaloc</c> string and a stringified <c>Name</c>
-          sequence as input and returns a fully formed URL string.</p>
-      </desc>
-    </func>
-    <func>
-      <name>resolve_str(NamingContext, NameString) -> Return</name>
-      <fsummary>Return the object associated, if any, with the given name string</fsummary>
-      <type>
-        <v>NameContext = #objref</v>
-        <v>NameString = string()</v>
-        <v>Return =  #objref |  {'EXCEPTION', NamingContext::InvalidName{}} |  {'EXCEPTION', NamingContext::NotFound{why, rest_of_name}} | {'EXCEPTION', NamingContext::CannotProceed{cxt, rest_of_name}}</v>
-      </type>
-      <desc>
-        <p>This operation takes a stringified <c>Name</c> sequence as input and
-          returns the associated, if any, object.</p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/Makefile b/lib/orber/doc/src/Makefile
deleted file mode 100644
index c77345f12b..0000000000
--- a/lib/orber/doc/src/Makefile
+++ /dev/null
@@ -1,172 +0,0 @@
-#
-# %CopyrightBegin%
-#
-# Copyright Ericsson AB 1997-2017. All Rights Reserved.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-#     http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-#
-# %CopyrightEnd%
-#
-#
-include $(ERL_TOP)/make/target.mk
-include $(ERL_TOP)/make/$(TARGET)/otp.mk
-
-# ----------------------------------------------------
-# Application version
-# ----------------------------------------------------
-include ../../vsn.mk
-VSN=$(ORBER_VSN)
-APPLICATION=orber
-
-# ----------------------------------------------------
-# Release directory specification
-# ----------------------------------------------------
-RELSYSDIR = $(RELEASE_PATH)/lib/$(APPLICATION)-$(VSN)
-
-# ----------------------------------------------------
-# Target Specs
-# ----------------------------------------------------
-XML_APPLICATION_FILES = ref_man.xml
-XML_REF3_FILES = \
-	any.xml \
-	corba.xml \
-	corba_object.xml \
-	orber.xml \
-	CosNaming.xml \
-	CosNaming_NamingContext.xml \
-	CosNaming_NamingContextExt.xml \
-	CosNaming_BindingIterator.xml \
-	lname.xml \
-	lname_component.xml \
-	orber_ifr.xml \
-	orber_tc.xml \
-	Module_Interface.xml \
-	interceptors.xml \
-	fixed.xml \
-	orber_diagnostics.xml \
-	orber_acl.xml
-
-XML_PART_FILES = \
-	part.xml
-
-XML_CHAPTER_FILES = \
-	ch_contents.xml \
-	ch_introduction.xml \
-	ch_orber_kernel.xml \
-	ch_ifr.xml \
-	ch_install.xml \
-	ch_idl_to_erlang_mapping.xml \
-	ch_naming_service.xml \
-	ch_stubs.xml \
-	ch_security.xml \
-	notes.xml \
-	ch_exceptions.xml \
-	ch_interceptors.xml \
-	ch_orberweb.xml \
-	ch_debugging.xml
-
-BOOK_FILES = book.xml
-
-XML_FILES = $(BOOK_FILES) $(XML_APPLICATION_FILES) $(XML_REF3_FILES) \
-            $(XML_PART_FILES) $(XML_CHAPTER_FILES)
-
-TECHNICAL_DESCR_FILES =
-
-GIF_FILES = \
-	name.gif \
-	orbs.gif \
-	theORB.gif \
-	iiop.gif \
-	dependent.gif \
-	interceptor_operations.gif \
-	menuframe.gif \
-	dataframe1.gif \
-	dataframe2.gif \
-	dataframe3.gif \
-	dataframe4.gif \
-	dataframe5.gif \
-	dataframe6.gif \
-	dataframe7.gif \
-	dataframe8.gif \
-	firewall_nat.gif
-
-# ----------------------------------------------------
-
-INTERNAL_HTML_FILES = $(TECHNICAL_DESCR_FILES:%.xml=$(HTMLDIR)/%.html)
-
-HTML_FILES = $(XML_APPLICATION_FILES:%.xml=$(HTMLDIR)/%.html) \
-	$(XML_CHAPTER_FILES:%.xml=$(HTMLDIR)/%.html) \
-	$(XML_PART_FILES:%.xml=$(HTMLDIR)/%.html)
-
-INFO_FILE = ../../info
-EXTRA_FILES = \
-	$(DEFAULT_GIF_FILES) \
-	$(DEFAULT_HTML_FILES) \
-	$(XML_REF3_FILES:%.xml=$(HTMLDIR)/%.html)
-
-MAN3_FILES = $(XML_REF3_FILES:%.xml=$(MAN3DIR)/%.3)
-
-HTML_REF_MAN_FILE = $(HTMLDIR)/index.html
-
-TOP_PDF_FILE = $(PDFDIR)/$(APPLICATION)-$(VSN).pdf
-
-# ----------------------------------------------------
-# FLAGS
-# ----------------------------------------------------
-XML_FLAGS +=
-DVIPS_FLAGS +=
-
-# ----------------------------------------------------
-# Targets
-# ----------------------------------------------------
-$(HTMLDIR)/%.gif: %.gif
-	$(INSTALL_DATA) $< $@
-
-
-docs: pdf html man
-
-$(TOP_PDF_FILE): $(XML_FILES)
-
-pdf: $(TOP_PDF_FILE)
-
-html: gifs $(HTML_REF_MAN_FILE)
-
-clean clean_docs:
-	rm -rf $(HTMLDIR)/*
-	rm -f $(MAN3DIR)/*
-	rm -f $(TOP_PDF_FILE) $(TOP_PDF_FILE:%.pdf=%.fo)
-	rm -f errs core *~
-	rm -f $(JD_HTML) $(JD_PACK)
-
-man: $(MAN3_FILES)
-
-gifs: $(GIF_FILES:%=$(HTMLDIR)/%)
-
-debug opt:
-
-# ----------------------------------------------------
-# Release Target
-# ----------------------------------------------------
-include $(ERL_TOP)/make/otp_release_targets.mk
-
-release_docs_spec: docs
-	$(INSTALL_DIR) "$(RELSYSDIR)/doc/pdf"
-	$(INSTALL_DATA) $(TOP_PDF_FILE) "$(RELSYSDIR)/doc/pdf"
-	$(INSTALL_DIR) "$(RELSYSDIR)/doc/html"
-	$(INSTALL_DATA) $(HTMLDIR)/* \
-		"$(RELSYSDIR)/doc/html"
-	$(INSTALL_DATA) $(INFO_FILE) "$(RELSYSDIR)"
-	$(INSTALL_DIR) "$(RELEASE_PATH)/man/man3"
-	$(INSTALL_DATA) $(MAN3DIR)/* "$(RELEASE_PATH)/man/man3"
-
-release_spec:
diff --git a/lib/orber/doc/src/Module_Interface.xml b/lib/orber/doc/src/Module_Interface.xml
deleted file mode 100644
index a809bcf02f..0000000000
--- a/lib/orber/doc/src/Module_Interface.xml
+++ /dev/null
@@ -1,356 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>1999</year>
-      <year>2016</year>
-      <holder>Ericsson AB, All Rights Reserved</holder>
-    </copyright>
-    <legalnotice>
-  Licensed under the Apache License, Version 2.0 (the "License");
-  you may not use this file except in compliance with the License.
-  You may obtain a copy of the License at
- 
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
-
-  The Initial Developer of the Original Code is Ericsson AB.
-    </legalnotice>
-
-    <title>Module_Interface</title>
-    <prepared></prepared>
-    <docno></docno>
-    <checked></checked>
-    <date>1999-09-03</date>
-    <rev>A</rev>
-  </header>
-  <module>Module_Interface</module>
-  <modulesummary>Orber generated stubs/skeletons.</modulesummary>
-  <description>
-    <p>This module contains the stub/skeleton functions generated by IC.</p>
-    <p>Starting a Orber server can be done in three ways:</p>
-    <list type="bulleted">
-      <item>Normal - when the server dies Orber forgets all knowledge of the server.</item>
-      <item>Supervisor child - adding the configuration parameter <c>{sup_child, true}</c>
-       the <c>oe_create_link/2</c> function returns <c>{ok, Pid, ObjRef}</c> which
-       can be handled by the application <em>supervisor/stdlib-1.7</em> or later. </item>
-      <item>Persistent object reference - adding the configuration parameters <c>{persistent, true}</c>
-       and <c>{regname, {global, term()}}</c> Orber will remember the object reference until the
-       server terminates with reason <em>normal</em> or <em>shutdown</em>. Hence,
-       if the server is started as a <em>transient</em> supervisor child we do not
-       receive a 'OBJECT_NOT_EXIST' exception when it has crashed and is being restarted.</item>
-    </list>
-    <p>The Orber stub can be used to start a <c>pseudo object</c>, which will create a non-server implementation.
-      A pseudo object introduce some limitations:</p>
-    <list type="bulleted">
-      <item>The functions <c>oe_create_link/2</c> is equal to <c>oe_create/2</c>, i.e.,
-       no link can or will be created.</item>
-      <item>The <c>BIF:s self()</c> and <c>process_flag(trap_exit,true)</c> behaves incorrectly.</item>
-      <item>The <c>IC</c> option <c>{{impl, "M::I"}, "other_impl"}</c> has no effect. The call-back
-       functions must be implemented in a file called <c>M_I_impl.erl</c></item>
-      <item>The <c>IC</c> option <c>from</c> has no effect. </item>
-      <item>The call-back functions must be implemented as if the <c>IC</c> option 
-      <c>{this, "M::I"}</c> was used.</item>
-      <item>Server <c>State</c> changes have no effect. The user can provide information via
-       the <c>Env</c> start parameter and the State returned from <c>init/2</c> will be the State
-       passed in following invocations.</item>
-      <item>If a call-back function replies with the <c>Timeout</c> parameter set it have no effect.</item>
-      <item>Operations defined as <c>oneway</c> are blocking until the operation replies.</item>
-      <item>The option <c>{pseudo, true}</c> overrides all other start options.</item>
-      <item>Only the functions, besides own definitions, <c>init/2</c> (called via oe_create*/2) and 
-      <c>terminate/2</c> (called via corba:dispose/1) must be implemented.</item>
-    </list>
-    <p>By adopting the rules for <c>pseudo</c> objects described above we can use <c>oe_create/2</c>
-      to create <c>server</c> or <c>pseudo</c> objects, by excluding or including the 
-      option <c>{pseudo, true}</c>, without changing the call-back module.
-      </p>
-    <p>If you start a object without <c>{regname, RegName}</c> it can only be accessed through the returned object key. 
-      Started with a <c>{regname, RegName}</c> the name is registered locally or globally. 
-      </p>
-    <warning>
-      <p>To avoid flooding Orber with old object references start erlang using the flag 
-        <em>-orber objectkeys_gc_time Time</em>, which will remove all object references
-        related to servers being dead for Time seconds. To avoid extra overhead, i.e., performing
-        garbage collect if no persistent objects are started, the objectkeys_gc_time default value 
-        is <em>infinity</em>. For more information, see the orber and corba documentation.</p>
-    </warning>
-  </description>
-  <funcs>
-    <func>
-      <name>Module_Interface:typeID() -> TypeId</name>
-      <fsummary>Return the Type ID related to this stub/skeleton</fsummary>
-      <type>
-        <v>TypeId = string(), e.g., "IDL:Module/Interface:1.0"</v>
-      </type>
-      <desc>
-        <p>Returns the Type ID related to this stub/skeleton</p>
-      </desc>
-    </func>
-    <func>
-      <name>Module_Interface:oe_create() -> ObjRef</name>
-      <fsummary>Start a Orber server.</fsummary>
-      <type>
-        <v>ObjRef = #object reference</v>
-      </type>
-      <desc>
-        <p>Start a Orber server.</p>
-      </desc>
-    </func>
-    <func>
-      <name>Module_Interface:oe_create_link() -> ObjRef</name>
-      <fsummary>Start a linked Orber server.</fsummary>
-      <type>
-        <v>ObjRef = #object reference</v>
-      </type>
-      <desc>
-        <p>Start a linked Orber server.</p>
-      </desc>
-    </func>
-    <func>
-      <name>Module_Interface:oe_create(Env) -> ObjRef</name>
-      <fsummary>Start a Orber server.</fsummary>
-      <type>
-        <v>Env = term()</v>
-        <v>ObjRef = #object reference</v>
-      </type>
-      <desc>
-        <p>Start a Orber server passing Env to <c>init/1</c>.</p>
-      </desc>
-    </func>
-    <func>
-      <name>Module_Interface:oe_create_link(Env) -> ObjRef</name>
-      <fsummary>Start a linked Orber server.</fsummary>
-      <type>
-        <v>Env = term()</v>
-        <v>ObjRef = #object reference</v>
-      </type>
-      <desc>
-        <p>Start a linked Orber server passing Env to <c>init/1</c>.</p>
-      </desc>
-    </func>
-    <func>
-      <name>Module_Interface:oe_create(Env, Options) -> ObjRef</name>
-      <fsummary>Start a Orber stub/skeleton</fsummary>
-      <type>
-        <v>Env = term()</v>
-        <v>ObjRef = #object reference</v>
-        <v>Options = [{sup_child, false} | {persistent, Bool} | {regname, RegName} |  {pseudo, Bool} | {local_typecheck, Bool} | {survive_exit, Bool} | {create_options, [CreateOpts]}]</v>
-        <v>Bool = true | false</v>
-        <v>RegName = {global, term()} | {local, atom()}</v>
-        <v>CreateOpts = {debug, [Dbg]} | {timeout, Time}</v>
-        <v>Dbg = trace | log | statistics | {log_to_file, FileName}</v>
-      </type>
-      <desc>
-        <p>Start a Orber server passing Env to <c>init/1</c>.</p>
-        <p>If the option <c>{pseudo, true}</c> is used, all other options are overridden.
-          As default, this option is set to false.</p>
-        <p>This function cannot be used for starting a server as supervisor child.
-          If started as <c>persistent</c>, the options <c>[{persistent, true}, {regname, {global, term()}}]</c> must be used and
-          Orber will only forget the object reference if it terminates with reason <em>normal</em> or <em>shutdown</em>.</p>
-        <p>The option <c>{local_typecheck, boolean()}</c>, which overrides the
-          <seealso marker="ch_install#flags">Local Typechecking</seealso>
-          environment flag, turns on or off typechecking. If activated,
-          parameters, replies and raised exceptions will be checked to ensure that
-          the data is correct, when invoking operations on CORBA Objects within
-          the same Orber domain. Due to the extra overhead, this option 
-          <em>MAY ONLY</em> be used during testing and development.</p>
-        <p><c>{survive_exit, boolean()}</c> overrides the
-          <seealso marker="ch_install#flags">EXIT Tolerance</seealso>
-          environment flag. If activated, the server will not terminate, even though
-          the call-back module returns EXIT.</p>
-        <p><c>Time</c> specifies how long time, in milliseconds, the server is allowed to
-          spend initializing. For more information about the <c>Dbg</c> options,
-          see the <c>sys</c> module.</p>
-      </desc>
-    </func>
-    <func>
-      <name>Module_Interface:oe_create_link(Env, Options) -> Return</name>
-      <fsummary>Start a Orber stub/skeleton</fsummary>
-      <type>
-        <v>Env = term()</v>
-        <v>Return = ObjRef | {ok, Pid, ObjRef}</v>
-        <v>ObjRef = #object reference</v>
-        <v>Options = [{sup_child, Bool} | {persistent, Bool} | {regname, RegName} | {pseudo, Bool} | {local_typecheck, Bool} | {survive_exit, Bool} |  {create_options, [CreateOpts]}]</v>
-        <v>Bool = true | false</v>
-        <v>RegName = {global, term()} | {local, atom()}</v>
-        <v>CreateOpts = {debug, [Dbg]} | {timeout, Time}</v>
-        <v>Dbg = trace | log | statistics | {log_to_file, FileName}</v>
-        <v></v>
-        <v></v>
-        <v></v>
-      </type>
-      <desc>
-        <p>Start a linked Orber server passing Env to <c>init/1</c>.</p>
-        <p>If the option <c>{pseudo, true}</c> is used, all other options are overridden and no link will be created.
-          As default, this option is set to false.</p>
-        <p>This function can be used for starting a server as persistent or supervisor child. At the moment
-          <c>[{persistent, true}, {regname, {global, term()}}]</c> must be used to start
-          a server as persistent, i.e., if a server died and is in the process of being restarted
-          a call to the server will not raise <c>'OBJECT_NOT_EXIST'</c> exception.
-          Orber will only forget the object reference if it terminates with reason <em>normal</em> or <em>shutdown</em>,
-          hence, the server must be started as <em>transient</em> (for more information see the
-          supervisor documentation).</p>
-        <p>The options <c>{local_typecheck, boolean()}</c> and <c>{survive_exit, boolean()}</c> 
-          behaves in the same way as for <c>oe_create/2</c>.</p>
-        <p><c>Time</c> specifies how long time, in milliseconds, the server is allowed to
-          spend initializing. For more information about the <c>Dbg</c> options,
-          see the <c>sys</c> module.</p>
-      </desc>
-    </func>
-    <func>
-      <name>Module_Interface:own_functions(ObjRef, Arg1, ..., ArgN) -> Reply</name>
-      <name>Module_Interface:own_functions(ObjRef, Options, Arg1, ..., ArgN) -> Reply</name>
-      <fsummary>User defined function which is not a part of Orber</fsummary>
-      <type>
-        <v>ObjRef = #object reference</v>
-        <v>Options = [Option] | Timeout</v>
-        <v>Option = {timeout, Timeout} | {context, [Context]}</v>
-        <v>Timeout = infinity | integer(milliseconds)</v>
-        <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
-        <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
-        <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
-        <v>Interface = string()</v>
-        <v>Options = [{Key, Value}]</v>
-        <v>Key = ssl_client_verify | ssl_client_depth | ssl_client_certfile | ssl_client_cacertfile |
-                 ssl_client_password | ssl_client_keyfile | ssl_client_ciphers | ssl_client_cachetimeout</v>
-        <v>Value = allowed value associated with the given key</v>
-        <v>ArgX = specified in the IDL-code.</v>
-        <v>Reply = specified in the IDL-code.</v>
-      </type>
-      <desc>
-        <p>The default value for the <c>Timeout</c> option is <c>infinity</c>.
-          IPv4 or IPv6 addresses are accepted as local Interface.</p>
-        <p>The <em>configuration</em> context is used to override the global
-           SSL client side 
-           <seealso marker="ch_install#config">configuration</seealso>.</p>
-        <p>To gain access to <c>#'IOP_ServiceContext'{}</c> record and the 
-          <c>?ORBER_GENERIC_CTX_ID</c> macro, you must add 
-          <c>-include_lib("orber/include/corba.hrl").</c> to your module.</p>
-      </desc>
-    </func>
-  </funcs>
-
-  <section>
-    <title>CALLBACK FUNCTIONS</title>
-    <p>The following functions should be exported from a <c>CORBA</c>
-      callback module. Note, a complete template of the call-back module can
-      be generated automatically by compiling the IDL-file with the IC option 
-      <c>{be,erl_template}</c>. One should also add
-      the same compile options, for example <c>this</c> or <c>from</c>,
-      used when generating the stub/skeleton modules.</p>
-  </section>
-  <funcs>
-    <func>
-      <name>Module_Interface_impl:init(Env) -> CallReply</name>
-      <fsummary>User defined function which is not a part of Orber</fsummary>
-      <type>
-        <v>Env = term()</v>
-        <v>CallReply = {ok, State} | {ok, State, Timeout} | ignore | {stop, StopReason}</v>
-        <v>State = term()</v>
-        <v>Timeout = int() >= 0 | infinity</v>
-        <v>StopReason = term()</v>
-      </type>
-      <desc>
-        <p>Whenever a new server is started, <em>init/1</em> is the first function called in the specified call-back module.</p>
-      </desc>
-    </func>
-    <func>
-      <name>Module_Interface_impl:terminate(Reason, State) -> ok</name>
-      <fsummary>User defined function which is not a part of Orber</fsummary>
-      <type>
-        <v>Reason = term()</v>
-        <v>State = term()</v>
-      </type>
-      <desc>
-        <p>This call-back function is called whenever the server is about to terminate.</p>
-      </desc>
-    </func>
-    <func>
-      <name>Module_Interface_impl:code_change(OldVsn, State, Extra) -> CallReply</name>
-      <fsummary>User defined function which is not a part of Orber</fsummary>
-      <type>
-        <v>OldVsn = undefined | term()</v>
-        <v>State = term()</v>
-        <v>Extra = term()</v>
-        <v>CallReply = {ok, NewState}</v>
-        <v>NewState = term()</v>
-      </type>
-      <desc>
-        <p>Update the internal <c>State</c>.</p>
-      </desc>
-    </func>
-    <func>
-      <name>Module_Interface_impl:handle_info(Info, State) -> CallReply</name>
-      <fsummary>User defined function which is not a part of Orber</fsummary>
-      <type>
-        <v>Info = term()</v>
-        <v>State = term()</v>
-        <v>CallReply = {noreply, State} | {noreply, State, Timeout} | {stop, StopReason, State}</v>
-        <v>Timeout = int() >= 0 | infinity</v>
-        <v>StopReason = normal | shutdown | term()</v>
-      </type>
-      <desc>
-        <p>If the configuration parameter <em>{{handle_info, "Module::Interface"}, true}</em>
-          is passed to IC and <em>process_flag(trap_exit,true)</em> is set in the <em>init()</em> 
-          call-back this function must be exported. </p>
-        <note>
-          <p>To be able to handle the <c>Timeout</c> option in <c>CallReply</c> in the call-back
-            module the configuration parameter <em>{{handle_info, "Module::Interface"}, true}</em> must
-            be passed to IC. </p>
-        </note>
-      </desc>
-    </func>
-    <func>
-      <name>Module_Interface_impl:own_functions(State, Arg1, ..., ArgN) -> CallReply</name>
-      <name>Module_Interface_impl:own_functions(This, State, Arg1, ..., ArgN) -> CallReply</name>
-      <name>Module_Interface_impl:own_functions(This, From, State, Arg1, ..., ArgN) -> ExtCallReply</name>
-      <name>Module_Interface_impl:own_functions(From, State, Arg1, ..., ArgN) -> ExtCallReply</name>
-      <fsummary>User defined function which is not a part of Orber</fsummary>
-      <type>
-        <v>This = the servers #object reference</v>
-        <v>State = term()</v>
-        <v>ArgX = specified in the IDL-code.</v>
-        <v>CallReply = {reply, Reply, State} | {reply, Reply, State, Timeout} |  {stop, StopReason, Reply, State} | {stop, StopReason, State} |  corba:raise(Exception)</v>
-        <v>ExtCallReply = CallReply | corba:reply(From, Reply), {noreply, State} | corba:reply(From, Reply), {noreply, State, Timeout}</v>
-        <v>Reply = specified in the IDL-code.</v>
-        <v>Timeout = int() >= 0 | infinity</v>
-        <v>StopReason = normal | shutdown | term()</v>
-      </type>
-      <desc>
-        <p>All two-way functions must return one of the listed replies or raise any of
-          the exceptions listed in the IDL code (i.e. raises(...)). 
-          If the IC compile options <em>this</em> and/or <em>from</em> are used,
-          the implementation must accept the <em>This</em> and/or <em>From</em> 
-          parameters.</p>
-      </desc>
-    </func>
-    <func>
-      <name>Module_Interface_impl:own_functions(State, Arg1, ..., ArgN) -> CastReply</name>
-      <name>Module_Interface_impl:own_functions(This, State, Arg1, ..., ArgN) -> CastReply</name>
-      <fsummary>User defined function which is not a part of Orber</fsummary>
-      <type>
-        <v>This = the servers #object reference</v>
-        <v>State = term()</v>
-        <v>CastReply = {noreply, State} | {noreply, State, Timeout} | {stop, StopReason, State}</v>
-        <v>ArgX = specified in the IDL-code.</v>
-        <v>Reply = specified in the IDL-code.</v>
-        <v>Timeout = int() >= 0 | infinity</v>
-        <v>StopReason = normal | shutdown | term()</v>
-      </type>
-      <desc>
-        <p>All one-way functions must return one of the listed replies. 
-          If the IC compile option <em>this</em> is used,
-          the implementation must accept the <em>This</em> parameter.</p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/Orber/InitialReference.java b/lib/orber/doc/src/Orber/InitialReference.java
deleted file mode 100644
index 35a8c2437b..0000000000
--- a/lib/orber/doc/src/Orber/InitialReference.java
+++ /dev/null
@@ -1,131 +0,0 @@
-/*
- * %CopyrightBegin%
- * 
- * Copyright Ericsson AB 1997-2016. All Rights Reserved.
- * 
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- *     http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- * 
- * %CopyrightEnd%
- *
- */
-/**
- * InitialReference is a class which generates the INIT reference
- * which can be used by the InitialReferences interface.
- */
-package Orber;
-
-public class InitialReference 
-{
-
-  /**
-   * Constructor.
-   */
-  public InitialReference(){;}
-
-  /**
-   * Returns the stringified objectreference to the initial reference server
-   */
-  public String stringified_ior(String host, int port)
-    {
-      String iorByteString;
-      String profileData;
-      String iorString;
-
-      // byte_order followed by ' {"", [{0, ' 
-      //      char iorBytesFirstPart[] = {0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0};
-      char iorBytesFirstPart[] = {0,0,0,0,0,0,0,32,73,68,76,58,79,114,98,101,114,47,73,110,105,116,105,97,108,82,101,102,101,114,101,110,99,101,115,58,49,46,48,0,0,0,0,1,0,0,0,0};
-      // the objectkey "INIT
-      char iorBytesLastPart[] = {0,0,0,4,73,78,73,84};
-
-      // Fix the ProfileData struct.
-      char pdPrefix[] = {0,1,0,0};
-      char nullbyte[] = {0};
-      profileData = new String(pdPrefix) + enc_ulong(host.length() + 1) + host + new String(nullbyte);
-      profileData = align(profileData, 2);
-      profileData +=  enc_ushort(port);
-      profileData = align(profileData, 4);
-      profileData += new String(iorBytesLastPart);
-      // Fix the whole IOR
-      iorByteString = new String(iorBytesFirstPart) + enc_ulong(profileData.length()) +
-	profileData;
-
-      //      System.out.print("Start[" + profileData.length() + "]");
-      //      System.out.print("[");
-      //      for(int x = 0; x < iorByteString.length(); x++)
-      //	{
-      //	  System.out.print((int) iorByteString.charAt(x) + ",");
-      //	}
-      //      System.out.println("]");
-
-      iorString = createIOR(iorByteString);
-      //      System.out.println(iorString);
-      return iorString;
-    }
-
-
-  private String enc_ushort(int s)
-    {
-      char byteArray[] = {(char) ((s >>> 8) & 0xFF),
-			  (char) ((s >>> 0) & 0xFF)};
-
-      return new String(byteArray);
-    }
-
-  private String enc_ulong(int l)
-    {
-      char byteArray[] = {(char) ((l >>> 24) & 0xFF),
-			  (char) ((l >>> 16) & 0xFF),
-			  (char) ((l >>> 8) & 0xFF),
-			  (char) ((l >>> 0) & 0xFF)};
-
-      return new String(byteArray);
-
-    }
-
-  private String createIOR(String bytes)
-    {
-      int i;
-      StringBuffer sb = new StringBuffer("IOR:");
-
-      for(i = 0; i < bytes.length(); i++)
-	{
-	  int b = bytes.charAt(i);
-	  if(b<0) b+= 256;
-	  int n1 = b / 16;
-	  int n2 = b % 16;
-	  int c1 = (n1 < 10) ? ('0' + n1) : ('a' + (n1 - 10));
-	  int c2 = (n2 < 10) ? ('0' + n2) : ('a' + (n2 - 10));
-	  sb.append((char)c1);
-	  sb.append((char)c2);	  
-	}
-
-      return sb.toString();
-    }
-
-  private String align(String buffer, int alignment)
-    {
-      String s = buffer;
-      char nullbyte[] = {0};
-
-      int remainder = alignment - (buffer.length() % alignment);
-      if (remainder == alignment) return s;
-
-      for (int i = 0; i < remainder; i++)
-	{
-	  s += new String(nullbyte);
-	}
-      return s;
-    }
-
-  
-}
diff --git a/lib/orber/doc/src/Orber/Makefile b/lib/orber/doc/src/Orber/Makefile
deleted file mode 100644
index 16a3994499..0000000000
--- a/lib/orber/doc/src/Orber/Makefile
+++ /dev/null
@@ -1,71 +0,0 @@
-#
-# %CopyrightBegin%
-# 
-# Copyright Ericsson AB 1997-2016. All Rights Reserved.
-# 
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-#     http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-# 
-# %CopyrightEnd%
-#
-#
-include $(ERL_TOP)/make/target.mk
-
-include $(ERL_TOP)/make/$(TARGET)/otp.mk
-
-# ----------------------------------------------------
-# Application version
-# ----------------------------------------------------
-include ../../vsn.mk
-VSN=$(ORBER_VSN)
-
-# ----------------------------------------------------
-# Release directory specification
-# ----------------------------------------------------
-RELSYSDIR = $(RELEASE_PATH)/lib/orber-$(VSN)
-
-#
-# JAVA macros
-#
-JAVA_CLASSES = \
-	InitialReference
-
-JAVA_FILES= $(JAVA_CLASSES:%=%.java)
-
-CLASSPATH = ../..
-
-# ----------------------------------------------------
-# Flags
-# ----------------------------------------------------
-JAVA_OPTIONS = 
-
-# ----------------------------------------------------
-# Make Rules
-# ----------------------------------------------------
-
-debug opt:
-
-clean:
-
-docs:
-
-# ----------------------------------------------------
-# Release Targets
-# ----------------------------------------------------
-include $(ERL_TOP)/make/otp_release_targets.mk
-
-release_spec: opt
-	$(INSTALL_DIR) $(RELSYSDIR)/java_src/Orber
-	$(INSTALL_DATA) $(JAVA_FILES) $(RELSYSDIR)/java_src/Orber
-
-release_docs_spec:
-
diff --git a/lib/orber/doc/src/any.xml b/lib/orber/doc/src/any.xml
deleted file mode 100644
index c94a2132d8..0000000000
--- a/lib/orber/doc/src/any.xml
+++ /dev/null
@@ -1,114 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>1998</year><year>2017</year>
-      <holder>Ericsson AB, All Rights Reserved</holder>
-    </copyright>
-    <legalnotice>
-  Licensed under the Apache License, Version 2.0 (the "License");
-  you may not use this file except in compliance with the License.
-  You may obtain a copy of the License at
- 
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
-
-  The Initial Developer of the Original Code is Ericsson AB.
-    </legalnotice>
-
-    <title>any</title>
-    <prepared></prepared>
-    <docno></docno>
-    <checked></checked>
-    <date>1998-04-20</date>
-    <rev>A</rev>
-  </header>
-  <module>any</module>
-  <modulesummary>the corba any type</modulesummary>
-  <description>
-    <p>This module contains functions that gives an interface to the CORBA any type.</p>
-    <p>Note that the <c>any</c> interface in orber does not contain a destroy 
-      function because the any type is represented as an Erlang record and 
-      therefor will be removed by the garbage collector when not in use.</p>
-    <p>The type <c>TC</c> used below describes an IDL type and is a tuple according 
-      to the to the Erlang language mapping.</p>
-    <p>The type <c>Any</c> used below is defined as:</p>
-    <code type="erl">-record(any, {typecode, value}).</code>
-    <p>where <c>typecode</c> is a TC tuple and <c>value</c> is an Erlang term of 
-      the type defined by the typecode field.</p>
-  </description>
-  <funcs>
-    <func>
-      <name>create() -> Result</name>
-      <name>create(Typecode, Value) -> Result</name>
-      <fsummary>Create an any record</fsummary>
-      <type>
-        <v>Typecode = TC</v>
-        <v>Value = term()</v>
-        <v>Result = Any</v>
-      </type>
-      <desc>
-        <p>The create/0 function creates an empty any record and the create/2 
-          function creates an initialized record.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_typecode(A, Typecode) -> Result</name>
-      <fsummary>Set the typecode field</fsummary>
-      <type>
-        <v>A = Any</v>
-        <v>Typecode = TC</v>
-        <v>Result = Any</v>
-      </type>
-      <desc>
-        <p>This function sets the typecode of <em>A</em> and returns a 
-          new any record.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_typecode(A) -> Result</name>
-      <fsummary>Fetch the typecode</fsummary>
-      <type>
-        <v>A = Any</v>
-        <v>Result = TC</v>
-      </type>
-      <desc>
-        <p>This function returns the typecode of <em>A</em>.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_value(A, Value) -> Result</name>
-      <fsummary>Set the value field</fsummary>
-      <type>
-        <v>A = Any</v>
-        <v>Value = term()</v>
-        <v>Result = Any</v>
-      </type>
-      <desc>
-        <p>This function sets the value of <em>A</em> and returns a 
-          new any record.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_value(A) -> Result</name>
-      <fsummary>Fetch the value</fsummary>
-      <type>
-        <v>A = Any</v>
-        <v>Result = term()</v>
-      </type>
-      <desc>
-        <p>This function returns the value of <em>A</em>.
-          </p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/book.xml b/lib/orber/doc/src/book.xml
deleted file mode 100644
index 81bd5a8f65..0000000000
--- a/lib/orber/doc/src/book.xml
+++ /dev/null
@@ -1,49 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE book SYSTEM "book.dtd">
-
-<book xmlns:xi="http://www.w3.org/2001/XInclude">
-  <header titlestyle="normal">
-    <copyright>
-      <year>1997</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>orber</title>
-    <prepared></prepared>
-    <docno></docno>
-    <date>1998-04-25</date>
-    <rev>2.0</rev>
-  </header>
-  <insidecover>
-  </insidecover>
-  <pagetext>Orber</pagetext>
-  <preamble>
-    <contents level="2"></contents>
-  </preamble>
-  <parts lift="no">
-    <xi:include href="part.xml"/>
-  </parts>
-  <applications>
-    <xi:include href="ref_man.xml"/>
-  </applications>
-  <releasenotes>
-    <xi:include href="notes.xml"/>
-  </releasenotes>
-  <listofterms></listofterms>
-  <index></index>
-</book>
-
diff --git a/lib/orber/doc/src/ch_contents.xml b/lib/orber/doc/src/ch_contents.xml
deleted file mode 100644
index b783e63aee..0000000000
--- a/lib/orber/doc/src/ch_contents.xml
+++ /dev/null
@@ -1,173 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>1999</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>The Orber Application</title>
-    <prepared></prepared>
-    <docno></docno>
-    <date>1998-05-05</date>
-    <rev>B</rev>
-    <file>ch_contents.xml</file>
-  </header>
-
-  <section>
-    <title>Content Overview</title>
-    <p>The Orber documentation is divided into three sections:
-      </p>
-    <list type="bulleted">
-      <item>
-        <p>PART ONE - The User's Guide  
-                    <br></br>
-Description of the Orber Application including IDL-to-Erlang
-          language mapping, services and a small tutorial demonstrating 
-          the development of a simple service.</p>
-      </item>
-      <item>
-        <p>PART TWO - Release Notes
-                    <br></br>
-A concise history of Orber.</p>
-      </item>
-      <item>
-        <p>PART THREE - The Reference Manual
-                    <br></br>
- A quick reference guide, including a
-          brief description, to all the functions available in Orber.</p>
-      </item>
-    </list>
-  </section>
-
-  <section>
-    <title>Brief Description of the User's Guide</title>
-    <p>The User's Guide  contains the following parts:</p>
-    <list type="bulleted">
-      <item>
-        <p>ORB kernel and IIOP support</p>
-      </item>
-      <item>
-        <p>Interface Repository</p>
-      </item>
-      <item>
-        <p>IDL to Erlang mapping</p>
-      </item>
-      <item>
-        <p>CosNaming Service</p>
-      </item>
-      <item>
-        <p>Resolving initial reference from Java or C++</p>
-      </item>
-      <item>
-        <p>Tutorial - creating a simple service </p>
-      </item>
-      <item>
-        <p>CORBA Exceptions </p>
-      </item>
-      <item>
-        <p>Interceptors</p>
-      </item>
-      <item>
-        <p>OrberWeb</p>
-      </item>
-      <item>
-        <p>Debugging
-          </p>
-      </item>
-    </list>
-
-    <section>
-      <title>ORB Kernel and IIOP Support</title>
-      <p>The ORB kernel which has IIOP support will allow the creation
-        of persistent server objects in Erlang. These objects can also
-        be accessed via Erlang and Java environments. For the moment a
-        Java enabled ORB is needed to generate Java from IDL to use
-        Java server objects (this has been tested using OrbixWeb).</p>
-    </section>
-
-    <section>
-      <title>Interface Repository</title>
-      <p>The IFR is an interface repository used for some type-checking
-        when coding/decoding IIOP. The IFR is capable of  storing all
-        interfaces and declarations of OMG IDL.</p>
-    </section>
-
-    <section>
-      <title>IDL to Erlang Mapping</title>
-      <p>The OMG IDL mapping for Erlang, which is necessary to access the
-        functionality of Orber, is described, The mapping structure is 
-        included as the basic and the constructed OMG IDL types 
-        references, invocations and Erlang characteristics. An example is
-        also provided.</p>
-    </section>
-
-    <section>
-      <title>CosNaming Service</title>
-      <p>Orber contains a CosNaming compliant service.</p>
-    </section>
-
-    <section>
-      <title>Resolving Initial References from Java or C++</title>
-      <p>A couple of classes are added to Orber to simplify initial 
-        reference access from Java or C++.
-        </p>
-      <p><em>Resolving initial reference from Java</em>        <br></br>
- A class with only one method which returns an <term id="IOR"><termdef>Interoperable Object Reference</termdef></term>on the
-        external string format to the INIT object (see "Interoperable
-        Naming Service" specification).</p>
-      <p><em>Resolving initial reference from C++</em>        <br></br>
-
-        A class (and header file) with only one method which returns
-        an IOR on the external  string format to the INIT object (see
-        "Interoperable Naming Service" specification).</p>
-    </section>
-
-    <section>
-      <title>Orber Stub/Skeleton</title>
-      <p>An example which describes the API and behavior of Orber stubs and skeletons. </p>
-    </section>
-
-    <section>
-      <title>CORBA Exceptions</title>
-      <p>A listing of all system exceptions supported by Orber and how one should
-        handle them. This chapter also describe how to generate user defined 
-        exceptions.</p>
-    </section>
-
-    <section>
-      <title>Interceptors</title>
-      <p>Descibes how to implement and activate interceptors.</p>
-    </section>
-
-    <section>
-      <title>OrberWeb</title>
-      <p>Offers the possibility to administrate and supervise Orber via a GUI.</p>
-    </section>
-
-    <section>
-      <title>Debugging</title>
-      <p>Describes how to use different tools when debugging and/or developing
-        new applications using Orber. Also includes a FAQ, which deal with
-        the most common mistakes when using Orber.
-        </p>
-    </section>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_debugging.xml b/lib/orber/doc/src/ch_debugging.xml
deleted file mode 100644
index debac4313e..0000000000
--- a/lib/orber/doc/src/ch_debugging.xml
+++ /dev/null
@@ -1,210 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>2001</year><year>2017</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>Debugging</title>
-    <prepared></prepared>
-    <docno></docno>
-    <date>2001-11-29</date>
-    <rev></rev>
-    <file>ch_debugging.xml</file>
-  </header>
-
-  <section>
-    <title>Tools and FAQ</title>
-    <p>Persons who use Orber for the first time may find it hard to tell what goes
-      wrong when trying to setup communication between an Orber-ORB and ORB:s supplied
-      by another vendor or another Orber-ORB. The purpose of this chapter is to inform
-      about the most common mistakes and what tools one can use to overcome these 
-      problems. </p>
-
-    <section>
-      <title>Tools</title>
-      <p>To begin with, Orber can be configured to run in debug mode. There are four ways
-        to set this parameter:</p>
-      <list type="bulleted">
-        <item><em>erl -orber orber_debug_level 10</em> - can be added to a start-script.</item>
-        <item><em>corba:orb_init([{orber_debug_level, 10}])</em> - this operation must
-         be invoked <em>before</em> starting Orber.</item>
-        <item><em>orber:configure(orber_debug_level, 10)</em> - this operation can
-         be invoked at any time.</item>
-        <item><em>OrberWeb</em> - via the <c>Configuration</c> menu one can easily change
-         the configuration. For more information, see the OrberWeb chapter in this
-         User's Guide.</item>
-      </list>
-      <p>When Orber runs i debug mode, printouts will be generated if anything abnormal occurs
-        (not necessarily an error). An error message typically looks like:</p>
-      <code type="none">
-=ERROR REPORT==== 29-Nov-2001::14:09:55 ===
-=================== Orber =================
-[410] corba:common_create(orber_test_server, [{pseudo,truce}]); 
-not a boolean(truce).
-===========================================
-      </code>
-      <p>In the example above, we tried to create an object with an incorrect option (i.e. should
-        have been <c>{pseudo,true}</c>).</p>
-      <p>If you are not able to solve the problem, you should include all generated reports when
-        contacting support or using the erlang-questions mailing list.</p>
-      <p>It is easy to forget to, for example, set all fields in a struct, which
-        one may not discover when developing an application using Orber. When using
-        a typed language, such faults would cause a compile time error. To avoid
-        these mistakes, Orber allows the user to activate automatic typechecking
-        of all local invocations of CORBA Objects. For this feature to be really
-        useful, the user must create test suites which cover as much as 
-        possible. For example, invoking an operation with invalid or incorrect
-        arguments should also be tested. This option can be activated for one object
-        or all object via:</p>
-      <list type="bulleted">
-        <item><em>'MyModuyle_MyInterface':oe_create(Env, [{local_typecheck, true}])</em> - 
-         This approach will only activate, or deactivate, typechecking for
-         the returned instance. Naturally, this option can also be passed
-         to <c>oe_create_link/2</c>, <c>corba:create/4</c> and 
-        <c>corba:create_link/4</c>.</item>
-        <item><em>erl -orber flags 2</em> - can be added to a start-script.
-         All object invocations will be typechecked, unless overridden by the
-         previous option.</item>
-        <item><em>corba:orb_init([{flags, 16#0002}])</em> - this operation must
-         be invoked <em>before</em> starting Orber. Behaves as the previous
-         option.</item>
-      </list>
-      <p>If incorrect data is passed or returned, Orber uses the <c>error_logger</c>
-        to generate logs, which can look like:</p>
-      <code type="none">
-=ERROR REPORT==== 10-Jul-2002::12:36:09 ===
-========= Orber Typecheck Request =========
-Invoked......: MyModule_MyInterface:foo/1
-Typecode.....: [{tk_enum,"IDL:MyModule/enumerant:1.0",
-                         "enumerant",
-                         ["one","two"]}]
-Arguments....: [three]
-Result.......: {'EXCEPTION',{'MARSHAL',[],102,'COMPLETED_NO'}}
-===========================================
-      </code>
-      <p>Note, that the arity is equivalent to the IDL-file. In the example above,
-        an undefined enumerant was used. In most cases, it is useful to set the
-        configuration parameter <c>orber_debug_level 10</c> as well. Due to the
-        extra overhead, this option <em>MAY ONLY</em> be used during testing and
-        development.
-        For more information, see also
-        <seealso marker="ch_install#config">configuration settings</seealso>.</p>
-      <p>It is also possible to trace all communication between an Orber-ORB and, for example,
-        a Java-ORB, communicating via IIOP. All you need to do is to activate an 
-        <seealso marker="ch_interceptors">interceptor</seealso>. Normally, the users must
-        implement the interceptor themselves, but for your convenience Orber includes three
-        pre-compiled interceptors called <c>orber_iiop_tracer</c>,
-        <c>orber_iiop_tracer_silent</c> and <c>orber_iiop_tracer_stealth</c>.</p>
-      <warning>
-        <p>Logging all traffic is <em>expensive</em>. Hence, only use the supplied 
-          interceptors during test and development.</p>
-      </warning>
-      <p>The <c>orber_iiop_tracer</c> and <c>orber_iiop_tracer_silent</c> interceptors
-        uses the <c>error_logger</c> module to generate the logs. If the traffic 
-        is intense you probably want to write the reports to a log-file. 
-        This is done by, for example, invoking:</p>
-      <code type="erl">
-erl> error_logger:tty(false). 
-erl> error_logger:logfile({open, "/tmp/IIOPTrace"}). 
-      </code>
-      <p>The <c>IIOPTrace</c> file will contain, if you use the <c>orber_iiop_tracer</c> 
-        interceptor, reports which looks like:</p>
-      <code type="none">
-=INFO REPORT==== 13-Jul-2005::18:22:39 ===
-=============== new_out_connection =======
-Node      : myNode@myHost
-From      : 192.0.0.10:47987
-To        : 192.0.0.20:4001
-==========================================
-
-=INFO REPORT==== 29-Nov-2001::15:26:28 ===
-=============== out_request ==============
-Connection: {"192.0.0.20",4001,"192.0.0.10",47987}
-Operation : resolve
-Parameters: [[{'CosNaming_NameComponent',
-                "AIK","SwedishIcehockeyChampions"}]]
-Context   : [{'IOP_ServiceContext',1,
-               {'CONV_FRAME_CodeSetContext',65537,65801}}]
-==========================================
-      </code>
-      <p>The <c>orber_iiop_tracer_silent</c> will not log GIOP encoded data. To activate
-        one the interceptors, you have two options:</p>
-      <list type="bulleted">
-        <item><em>erl -orber interceptors "{native,[orber_iiop_tracer]}"</em> - can be added to a start-script.</item>
-        <item><em>corba:orb_init([{interceptors, {native, [orber_iiop_tracer_silent]}}])</em> - this operation must
-         be invoked <em>before</em> starting Orber.</item>
-      </list>
-      <p>It is also possible to active and deactivate an interceptor during
-        run-time, but this will only affect currently existing connections. 
-        For more information, consult Orber's Reference Manual regarding the
-        operations <c>orber:activate_audit_trail/0/1</c> and
-        <c>orber:activate_audit_trail/0/1.</c></p>
-    </section>
-
-    <section>
-      <title>FAQ</title>
-      <p><em>Q: When my client, typically written in C++ or Java, invoke narrow on an Orber  object reference it fails?</em></p>
-      <p>A: You must register your application in the IFR by invoking <c>oe_register()</c>. 
-        If the object was created by a COS-application, you must run install 
-        (e.g. <c>cosEventApp:install()</c>).</p>
-      <p>A: Confirm, by consulting the IDL specifications, that the received object reference really
-        inherit from the interface you are trying to narrow it to.</p>
-      <br></br>
-      <p><em>Q: I am trying to register my application in the IFR but it fails. Why?</em></p>
-      <p>A: If one, or more, interface in your IDL-specification inherits from
-        other interface(s), you must register them before registering your
-        application. Note, this also apply when you inherit interfaces
-        supported by a COS-application. Hence, they must be installed prior to
-        registration of your application.</p>
-      <br></br>
-      <p><em>Q: I have a Orber client and server residing on two different Orber instances but I only get the 'OBJECT_NOT_EXIST' exception, even though I am sure that the object is still alive?</em></p>
-      <p>A: If the two Orber-ORB's are not intended to be a part of multi-node ORB, make sure that the
-        two Orber-ORB's have different <em>domain</em> names set (see
-        <seealso marker="ch_install#config">configuration settings</seealso>). The easiest way
-        to confirm this is to invoke <c>orber:info()</c> on each node.</p>
-      <br></br>
-      <p><em>Q: When I'm trying to install and/or start Orber it fails?</em></p>
-      <p>A: Make sure that no other Orber-ORB is already running on the same node. If so,
-        change the <c>iiop_port</c> configuration parameter (see
-        <seealso marker="ch_install#config">configuration settings</seealso>).</p>
-      <br></br>
-      <p><em>Q: My Orber server is invoked via IIOP but Orber cannot marshal the  reply?</em></p>
-      <p>A: Consult your IDL file to confirm that your replies are of the correct
-        type. If it is correct and the return type is, for example,
-        a struct, make sure you have set every field in the struct. If
-        you do not do that it will be set to the atom 'undefined', which
-        most certainly is not correct.</p>
-      <br></br>
-      <p>A: Check that you handle <c>inout</c> and <c>out</c> parameters correctly
-        (see the IDL specification). For example, a function which have one
-        out-parameter and should return void, then your call-back module
-        should return <c>{reply, {ok, OutParam}, State}</c>. Note, even though
-        the return value is void (IDL) you must reply with ok.</p>
-      <br></br>
-      <p><em>Q: I cannot run Orber as a multi-node ORB?</em></p>
-      <p>A: Make sure that the Erlang distribution have been started for each
-        node and the <c>cookies</c> are correct. For more information,
-        consult the <c>System Documentation</c></p>
-      <br></br>
-    </section>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_exceptions.xml b/lib/orber/doc/src/ch_exceptions.xml
deleted file mode 100644
index 17657d0d4a..0000000000
--- a/lib/orber/doc/src/ch_exceptions.xml
+++ /dev/null
@@ -1,238 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>2001</year><year>2017</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>CORBA System and User Defined Exceptions</title>
-    <prepared></prepared>
-    <docno></docno>
-    <date>2000-12-19</date>
-    <rev></rev>
-    <file>ch_exceptions.xml</file>
-  </header>
-
-  <section>
-    <title>System Exceptions</title>
-    <p><c>Orber</c>, or any other <c>ORB</c>, may raise a <c>System Exceptions</c>.
-      These exceptions contain status- and minor-fields and may not appear in the
-      operations raises exception IDL-definition.</p>
-
-    <section>
-      <title>Status Field</title>
-      <p>The status field indicates if the request was completed or not and will be
-        assigned one of the following Erlang atoms:</p>
-      <table>
-        <row>
-          <cell align="center" valign="middle"><em>Status</em></cell>
-          <cell align="center" valign="middle"><em>Description</em></cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">'COMPLETED_YES'</cell>
-          <cell align="left" valign="middle">The operation was invoked on the target object but an error occurred after the object replied. This occur, for example, if a server replies but Orber is not able to marshal and send the reply to the  client ORB.</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">'COMPLETED_NO'</cell>
-          <cell align="left" valign="middle">Orber failed to invoke the operation on the target object. This occur, for example, if the object no longer exists.</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">'COMPLETED_MAYBE'</cell>
-          <cell align="left" valign="middle">Orber invoked the operation on the target object but an error occurred and it is impossible to decide if the request really reached the object or not.</cell>
-        </row>
-        <tcaption>System Exceptions Status</tcaption>
-      </table>
-    </section>
-
-    <section>
-      <title>Minor Field</title>
-      <p>The minor field contains an integer (VMCID), which is related to a more
-        specific reason why an invocation failed. The function 
-        <c>orber:exception_info/1</c> can be used to map the minor code to a string. 
-        Note, for VMCID:s not assigned by the OMG or Orber, the documentation
-        for that particular ORB must be consulted.</p>
-    </section>
-
-    <section>
-      <title>Supported System Exceptions</title>
-      <p>The OMG CORBA specification defines the following exceptions:</p>
-      <list type="bulleted">
-        <item><em>'BAD_CONTEXT'</em> - if a request does not contain a correct
-         context this exception is raised.</item>
-        <item><em>'BAD_INV_ORDER'</em> - this exception indicates that operations
-         has been invoked operations in the wrong order, which would cause,
-         for example, a dead-lock.</item>
-        <item><em>'BAD_OPERATION'</em> - raised if the target object exists, but
-         that the invoked operation is not supported.</item>
-        <item><em>'BAD_PARAM'</em> - is thrown if, for example, a parameter is out
-         of range or otherwise considered illegal.</item>
-        <item><em>'BAD_TYPECODE'</em> - if illegal type code is passed, for example,
-         encapsulated in an any data type the <c>'BAD_TYPECODE'</c> exception
-         will be raised.</item>
-        <item><em>'BAD_QOS'</em> - raised whenever an object cannot support the 
-         required quality of service.</item>
-        <item><em>'CODESET_INCOMPATIBLE'</em> - raised if two ORB's cannot 
-         communicate due to different representation of, for example, 
-        <c>char</c> and/or <c>wchar</c>.</item>
-        <item><em>'COMM_FAILURE'</em> - raised if an ORB is unable to setup 
-         communication or it is lost while an operation is in progress.</item>
-        <item><em>'DATA_CONVERSION'</em> - raised if an ORB cannot convert data 
-         received to the native representation. See also the 
-        <c>'CODESET_INCOMPATIBLE'</c> exception.</item>
-        <item><em>'FREE_MEM'</em> - the ORB failed to free dynamic memory and 
-         failed.</item>
-        <item><em>'IMP_LIMIT'</em> - an implementation limit was exceeded in the
-         ORB at run time. A object factory may, for example, limit the
-         number of object clients are allowed to create.</item>
-        <item><em>'INTERNAL'</em> - an internal failure occurred in an ORB, which
-         is unrecognized. You may consider contacting the ORB providers 
-         support.</item>
-        <item><em>'INTF_REPOS'</em> - the ORB was not able to reach the interface
-         repository, or some other failure relating to the interface 
-         repository is detected.</item>
-        <item><em>'INITIALIZE'</em> - the ORB initialization failed due to, for
-         example, network or configuration error.</item>
-        <item><em>'INVALID_TRANSACTION'</em> - is raised if the request carried an
-         invalid transaction context.</item>
-        <item><em>'INV_FLAG'</em> - an invalid flag was passed to an operation, 
-         which caused, for example, a connection to be closed.</item>
-        <item><em>'INV_IDENT'</em> - this exception indicates that an IDL 
-         identifier is incorrect.</item>
-        <item><em>'INV_OBJREF'</em> - this exception is raised if an object 
-         reference is malformed or a nil reference (see 
-         also corba:create_nil_objref/0).</item>
-        <item><em>'INV_POLICY'</em> - the invocation cannot be made due to an
-         incompatibility between policy overrides that apply to the
-         particular invocation.</item>
-        <item><em>'MARSHAL'</em> - this exception may be raised by the client- or
-         server-side when either ORB is unable to marshal/unmarshal requests or
-         replies.</item>
-        <item><em>'NO_IMPLEMENT'</em> - if the operation exists but no implementation
-         exists, this exception is raised.</item>
-        <item><em>'NO_MEMORY'</em> - the ORB has run out of memory.</item>
-        <item><em>'NO_PERMISSION'</em> - the caller has insufficient privileges, 
-         such as, for example, bad <c>SSL</c> certificate.</item>
-        <item><em>'NO_RESOURCES'</em> - a general platform resource limit 
-         exceeded.</item>
-        <item><em>'NO_RESPONSE'</em> - no response available of a deferred
-         synchronous request.</item>
-        <item><em>'OBJ_ADAPTER'</em> - indicates administrative mismatch; the object
-         adapter is not able to associate an object with the implementation
-         repository.</item>
-        <item><em>'OBJECT_NOT_EXIST'</em> - the object have been disposed or 
-         terminated; clients should remove all copies of the object reference
-         and initiate desired recovery process.</item>
-        <item><em>'PERSIST_STORE'</em> - the ORB was not able to establish a
-         connection to its persistent storage or data contained in the
-         the storage is corrupted.</item>
-        <item><em>'REBIND'</em> - a request resulted in, for example, a 
-        <c>'LOCATION_FORWARD'</c> message; if the policies are incompatible 
-         this exception is raised.</item>
-        <item><em>'TIMEOUT'</em> - raised if a request fail to complete within the 
-         given time-limit.</item>
-        <item><em>'TRANSACTION_MODE'</em> - a transaction policy mismatch detected.</item>
-        <item><em>'TRANSACTION_REQUIRED'</em> - a transaction is required for the
-         invoked operation but the request contained no transaction context.</item>
-        <item><em>'TRANSACTION_ROLLEDBACK'</em> - the transaction associated with
-         the request has already been rolled back or will be.</item>
-        <item><em>'TRANSACTION_UNAVAILABLE'</em> - no transaction context can be
-         supplied since the ORB is unable to contact the Transaction
-         Service.</item>
-        <item><em>'TRANSIENT'</em> - the ORB could not determine the current status
-         of an object since it could not be reached. The error may be
-         temporary.</item>
-        <item><em>'UNKNOWN'</em> - is thrown if an implementation throws a 
-         non-CORBA, or unrecognized, exception.</item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>User Defined Exceptions</title>
-    <p>User exceptions is defined in IDL-files and is listed in operations raises
-      exception listing. For example, if we have the following IDL code:</p>
-    <code type="none">
-module MyModule {
-
-  exception MyException {};
-  exception MyExceptionMsg { string ExtraInfo; };
-
-  interface MyInterface {
-
-    void foo() 
-      raises(MyException);
-
-    void bar() 
-      raises(MyException, MyExceptionMsg);
-
-    void baz();
-  };
-};    
-    </code>
-  </section>
-
-  <section>
-    <title>Throwing Exceptions</title>
-    <p>To be able to raise <c>MyException</c> or <c>MyExceptionMsg</c> exceptions, 
-      the generated <c>MyModule.hrl</c> must be included, and typical usage is:</p>
-    <code type="erl">
--module('MyModule_MyInterface_impl').
--include("MyModule.hrl").
-
-bar(State) ->
-    case TestingSomething of
-        ok ->
-           {reply, ok, State};
-        {error, Reason} when list(Reason) ->
-           corba:raise(#'MyModule_MyExceptionMsg'{'ExtraInfo' = Reason});
-        error ->
-           corba:raise(#'MyModule_MyException'{})
-    end.
-    </code>
-  </section>
-
-  <section>
-    <title>Catching Exceptions</title>
-    <p>Depending on which operation we invoke we must be able to handle:</p>
-    <list type="bulleted">
-      <item>foo - <c>MyException</c> or a system exception.</item>
-      <item>bar - <c>MyException</c>, <c>MyExceptionMsg</c> or a system
-       exception.</item>
-      <item>baz - a system exception.</item>
-    </list>
-    <p>Catching and matching exceptions can bee done in different ways:</p>
-    <code type="none">
-    case catch 'MyModule_MyInterface':bar(MIReference) of
-        ok ->
-           %% The operation raised no exception.
-           ok;
-        {'EXCEPTION', #'MyModule_MyExceptionMsg'{'ExtraInfo' = Reason}} ->
-           %% If we want to log the Reason we must extract 'ExtraInfo'.
-           error_logger:error_msg("Operation 'bar' raised: ~p~n", [Reason]),
-           ... do something ...;
-        {'EXCEPTION', E} when record(E, 'OBJECT_NOT_EXIST') ->
-           ... do something ...;
-        {'EXCEPTION', E} ->
-           ... do something ...
-    end.
-    </code>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_idl_to_erlang_mapping.xml b/lib/orber/doc/src/ch_idl_to_erlang_mapping.xml
deleted file mode 100644
index eaa88f24f1..0000000000
--- a/lib/orber/doc/src/ch_idl_to_erlang_mapping.xml
+++ /dev/null
@@ -1,1504 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>1997</year><year>2017</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>OMG IDL to Erlang Mapping</title>
-    <prepared></prepared>
-    <docno></docno>
-    <date>1998-10-10</date>
-    <rev></rev>
-    <file>ch_idl_to_erlang_mapping.xml</file>
-  </header>
-
-  <section>
-    <title>OMG IDL to Erlang Mapping - Overview</title>
-    <p>The purpose of OMG IDL, <em>Interface Definition Language</em>, mapping
-      is to act as translator between platforms and languages. An IDL 
-      specification is supposed to describe data types, object types etc.</p>
-    <p>CORBA is independent of the programming language used to construct
-      clients or implementations. In order to use the ORB, it is
-      necessary for programmers to know how to access ORB functionality 
-      from their programming languages. It translates different IDL constructs
-      to  a specific programming language. This chapter 
-      describes the mapping of OMG IDL constructs to the Erlang programming
-      language.</p>
-  </section>
-
-  <section>
-    <title>OMG IDL Mapping Elements</title>
-    <p>A complete language mapping will allow the programmer to have
-      access to all ORB functionality in a way that is convenient for
-      a specified programming language. 
-      </p>
-    <p>All mapping must define the following elements: 
-      </p>
-    <list type="bulleted">
-      <item>All OMG IDL basic and constructed types</item>
-      <item>References to constants defined in OMG IDL</item>
-      <item>References to objects defined in OMG IDL</item>
-      <item>Invocations of operations, including passing of
-       parameters and receiving of results</item>
-      <item>Exceptions, including what happens when an operation
-       raises an exception and how the exception parameters are
-       accessed</item>
-      <item>Access to attributes</item>
-      <item>Signatures for operations defined by the ORB, such as
-       dynamic invocation interface, the object adapters etc.</item>
-      <item>Scopes;
-       OMG IDL has several levels of scopes, which are mapped to Erlang's 
-       two scopes.</item>
-    </list>
-  </section>
-
-  <section>
-    <title>Getting Started</title>
-    <p>To begin with, we should decide which type of objects (i.e. servers) we
-      need and if two, or more, should export the same functionality. Let us
-      assume that we want to create a system for DB (database) access for different
-      kind of users. For example, anyone with a valid password may extract 
-      data, but only a few may update the DB. Usually, an application
-      is defined within a <c>module</c>, and all global datatypes are defined
-      on the top-level. To begin with we create a module and the interfaces we
-      need:</p>
-    <code type="none">
-// DB IDL
-#ifndef _DB_IDL_
-#define _DB_IDL_
-// A module is simply a container
-module DB {
-
-  // An interface maps to a CORBA::Object.
-  interface CommonUser {
-
-  };
-
-  // Inherit the Consumer interface
-  interface Administrator : CommonUser {
-
-  };
-
-  interface Access {
-
-  };
-
-};
-#endif    </code>
-    <p>Since the <c>Administrator</c> should be able to do the same things as the
-      <c>CommonUser</c>, the previous inherits from the latter. The <c>Access</c>
-      interface will grant access to the DB.
-      Now we are ready to define the functionality and data types we need. But, this
-      requires that we know a little bit more about the OMG IDL.</p>
-    <note>
-      <p>The OMG defines a set of reserved case insensitive key-words, which may
-        <em>NOT</em> be used as identifiers (e.g. module name). For more
-        information, see
-        <seealso marker="#key_words">Reserved Compiler Names and Keywords</seealso></p>
-    </note>
-  </section>
-
-  <section>
-    <title>Basic OMG IDL Types</title>
-    <p>The OMG IDL mapping is strongly typed and, even if you have a good knowledge
-      of CORBA types, it is essential to read carefully the following mapping to
-      Erlang types.</p>
-    <p>The mapping of basic types is straightforward. Note that the
-      OMG IDL double type is mapped to an Erlang float which does not
-      support the full double value range.</p>
-    <table>
-      <row>
-        <cell align="left" valign="middle">OMG IDL type</cell>
-        <cell align="left" valign="middle">Erlang type</cell>
-        <cell align="left" valign="middle">Note</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">float</cell>
-        <cell align="left" valign="middle">Erlang float</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">double</cell>
-        <cell align="left" valign="middle">Erlang float</cell>
-        <cell align="left" valign="middle">value range not supported</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">short</cell>
-        <cell align="left" valign="middle">Erlang integer</cell>
-        <cell align="left" valign="middle">-2^15 .. 2^15-1</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">unsigned short</cell>
-        <cell align="left" valign="middle">Erlang integer</cell>
-        <cell align="left" valign="middle">0 .. 2^16-1</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">long</cell>
-        <cell align="left" valign="middle">Erlang integer</cell>
-        <cell align="left" valign="middle">-2^31 .. 2^31-1</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">unsigned long</cell>
-        <cell align="left" valign="middle">Erlang integer</cell>
-        <cell align="left" valign="middle">0 .. 2^32-1</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">long long</cell>
-        <cell align="left" valign="middle">Erlang integer</cell>
-        <cell align="left" valign="middle">-2^63 .. 2^63-1</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">unsigned long long</cell>
-        <cell align="left" valign="middle">Erlang integer</cell>
-        <cell align="left" valign="middle">0 .. 2^64-1</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">char</cell>
-        <cell align="left" valign="middle">Erlang integer</cell>
-        <cell align="left" valign="middle">ISO-8859-1</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">wchar</cell>
-        <cell align="left" valign="middle">Erlang integer</cell>
-        <cell align="left" valign="middle">UTF-16 (ISO-10646-1:1993)</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">boolean</cell>
-        <cell align="left" valign="middle">Erlang atom</cell>
-        <cell align="left" valign="middle">true/false</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">octet</cell>
-        <cell align="left" valign="middle">Erlang integer</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">any</cell>
-        <cell align="left" valign="middle">Erlang record</cell>
-        <cell align="left" valign="middle">#any{typecode, value}</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">long double</cell>
-        <cell align="left" valign="middle">Not supported</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">Object</cell>
-        <cell align="left" valign="middle">Orber object reference</cell>
-        <cell align="left" valign="middle">Internal Representation</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">void</cell>
-        <cell align="left" valign="middle">Erlang atom</cell>
-        <cell align="left" valign="middle">ok</cell>
-      </row>
-      <tcaption>OMG IDL basic types</tcaption>
-    </table>
-    <p>The <c>any</c> value is written as a record with the field typecode which
-      contains the <term id="Type Code"><termdef>Type Code is a full definition of a type </termdef></term>representation,
-      <seealso marker="#tk_values">see also the Type Code table</seealso>,
-      and the value field itself.</p>
-    <p>Functions with return type <c>void</c> will return the atom <c>ok</c>.</p>
-  </section>
-
-  <section>
-    <title>Template OMG IDL Types and Complex Declarators</title>
-    <p>Constructed types all have native mappings as shown in the table
-      below.</p>
-    <table>
-      <row>
-        <cell align="left" valign="middle"><em>Type</em></cell>
-        <cell align="left" valign="middle"><em>IDL code</em></cell>
-        <cell align="left" valign="middle"><em>Maps to</em></cell>
-        <cell align="left" valign="middle"><em>Erlang code</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>string</em></cell>
-        <cell align="left" valign="middle">typedef string S;        <br></br>
-void op(in S a);</cell>
-        <cell align="left" valign="middle">Erlang string</cell>
-        <cell align="left" valign="middle">ok = op(Obj, "Hello World"),</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>wstring</em></cell>
-        <cell align="left" valign="middle">typedef wstring S;        <br></br>
-void op(in S a);</cell>
-        <cell align="left" valign="middle">Erlang list of Integers</cell>
-        <cell align="left" valign="middle">ok = op(Obj, "Hello World"),</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>sequence</em></cell>
-        <cell align="left" valign="middle">typedef sequence &lt;long, 3&gt; S;        <br></br>
-void op(in S a);</cell>
-        <cell align="left" valign="middle">Erlang list</cell>
-        <cell align="left" valign="middle">ok = op(Obj, [1, 2, 3]),</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>array</em></cell>
-        <cell align="left" valign="middle">typedef string S[2];        <br></br>
-void op(in S a);</cell>
-        <cell align="left" valign="middle">Erlang tuple</cell>
-        <cell align="left" valign="middle">ok = op(Obj, {"one", "two"}),</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>fixed</em></cell>
-        <cell align="left" valign="middle">typedef fixed&lt;3,2> myFixed;        <br></br>
-void op(in myFixed a);</cell>
-        <cell align="left" valign="middle">Erlang tuple</cell>
-        <cell align="left" valign="middle">MF = fixed:create(3, 2, 314),        <br></br>
-ok = op(Obj, MF),</cell>
-      </row>
-      <tcaption>OMG IDL Template and Complex Declarators</tcaption>
-    </table>
-
-    <section>
-      <title>String/WString Data Types</title>
-      <p>A <c>string</c> consists of all possible 8-bit quantities except null.
-        Most ORB:s uses, including Orber, the character set Latin-1 (ISO-8859-1).
-        The <c>wstring</c> type is represented as a list of integers, where
-        each integer represents a wide character. In this case Orber uses, as
-        most other ORB:s, the UTF-16 (ISO-10646-1:1993) character set.</p>
-      <p>When defining a a string or wstring they can be of limited length or
-        null terminated:</p>
-      <code type="none"><![CDATA[
-// Null terminated
-typedef string myString;
-typedef wstring myWString;
-// Maximum length 10 
-typedef string<10> myString10;
-typedef wstring<10> myWString10;
-      ]]></code>
-      <p>If we want to define a char/string or wchar/wstring constant, we can
-        use octal (\OOO - one, two or three octal digits), 
-        hexadecimal (\xHH - one or two hexadecimal digits) and unicode (\uHHHH -
-        one, two, three or four hexadecimal digits.) representation as well.
-        For example:</p>
-      <code type="none">
-const string  SwedensBestSoccerTeam = "\101" "\x49" "\u004B";
-const wstring SwedensBestHockeyTeam = L"\101\x49\u004B";
-const char  aChar  = '\u004B';  
-const wchar aWchar = L'\u004C';
-      </code>
-      <p>Naturally, we can use <c>"Erlang"</c>, <c>L"Rocks"</c>, <c>'A'</c>
-        and <c>L'A'</c> as well.</p>
-    </section>
-
-    <section>
-      <title>Sequence Data Type</title>
-      <p>A sequence can be defined to be of a maximum length or unbounded, and may 
-        contain Basic and Template types and scoped names:</p>
-      <code type="none"><![CDATA[
-typedef sequence <short, 1> aShortSequence;
-typedef sequence <long> aLongSequence;
-typedef sequence <aLongSequence> anEvenLongerSequence;
-      ]]></code>
-    </section>
-
-    <section>
-      <title>Array Data Type</title>
-      <p>Arrays are multidimensional, fixed-size arrays. The indices is language
-        mapping specific, which is why one should not pass them as arguments
-        to another ORB.</p>
-      <code type="none">
-typedef long myMatrix[2][3];
-      </code>
-    </section>
-
-    <section>
-      <title>Fixed Data Type</title>
-      <p>A Fixed Point literal consists of an integer part (decimal digits), 
-        decimal point and a fraction part (decimal digits),
-        followed by a <c>D</c> or <c>d</c>. Either the integer part or the
-        fraction part may be missing; the decimal point may be missing, 
-        but not d/D. The integer part must be a positive integer less than 32.
-        The Fraction part must be a positive integer less than or equal to
-        the Integer part.</p>
-      <code type="none">
-const fixed myFixed1 = 3.14D;
-const fixed myFixed2 = .14D;
-const fixed myFixed3 = 0.14D;
-const fixed myFixed4 = 3.D;
-const fixed myFixed5 = 3D;
-      </code>
-      <p>It is also possible to use unary (+-) and binary (+-*/) operators:</p>
-      <code type="none">
-const fixed myFixed6 = 3D + 0.14D;
-const fixed myFixed7 = -3.14D;
-      </code>
-      <p>The Fixed Point examples above are, so called, <em>anonymous</em> 
-        definitions. In later CORBA specifications these have been deprecated
-        as function parameters or return values. Hence, we strongly recommend that
-        you do not use them. Instead, you should use:</p>
-      <code type="none"><![CDATA[
-typedef fixed<5,3> myFixed53;
-const myFixed53 myFixed53constant = 03.140d;
-typedef fixed<3,2> myFixed32;
-const myFixed32 myFixed32constant = 3.14d;
-
-myFixed53 foo(in myFixed32 MF); // OK
-void bar(in fixed<5,3> MF); // Illegal
-      ]]></code>
-    </section>
-    <p>For more information, see <seealso marker="fixed">Fixed</seealso> in 
-      Orber's Reference Manual.</p>
-    <p>Now we continue to work on our IDL specification. To begin with, we want
-      to limit the size of the logon parameters (Id and password). Since the
-      <c>UserID</c> and <c>Password</c> parameters, only will be used when
-      invoking operations on the <c>Access</c> interface, we may choose to define
-      them within the scope that interface. To keep it simple our DB will contain
-      employee information. Hence, as the DB key we choose an integer
-      (<c>EmployeeNo</c>).</p>
-    <code type="none"><![CDATA[
-// DB IDL
-#ifndef _DB_IDL_
-#define _DB_IDL_
-module DB {
-
-  typedef unsigned long EmployeeNo;
-
-  interface CommonUser {
-
-     any lookup(in EmployeeNo ENo);
-
-  };
-
-  interface Administrator : CommonUser {
-
-     void delete(in EmployeeNo ENo);
-
-  };
-
-  interface Access {
-
-      typedef string<10> UserID;
-      typedef string<10> Password;
-
-      CommonUser logon(in UserID ID, in Password PW);
-
-  };
-
-};
-#endif    ]]></code>
-    <p>But what should, for example, the <c>lookup</c> operation return? One option
-      is to use the <c>any</c> data type. But, depending on what kind of data it
-      encapsulates, this datatype can be rather expensive to use. We might find a 
-      solution to our problems among the <c>Constructed</c> IDL types.</p>
-  </section>
-
-  <section>
-    <title>Constructed OMG IDL Types</title>
-    <p>Constructed types all have native mappings as shown in the table
-      below.</p>
-    <table>
-      <row>
-        <cell align="left" valign="middle"><em>Type</em></cell>
-        <cell align="left" valign="middle"><em>IDL code</em></cell>
-        <cell align="left" valign="middle"><em>Maps to</em></cell>
-        <cell align="left" valign="middle"><em>Erlang code</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>struct</em></cell>
-        <cell align="left" valign="middle">struct myStruct {        <br></br>
-long a;         <br></br>
-short b;        <br></br>
-};        <br></br>
-void op(in myStruct a);</cell>
-        <cell align="left" valign="middle">Erlang record</cell>
-        <cell align="left" valign="middle">ok = op(Obj, #'myStruct'{a=300, b=127}),</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>union</em></cell>
-        <cell align="left" valign="middle">union myUnion switch(long) {        <br></br>
-case 1: long a;        <br></br>
-};        <br></br>
-void op(in myUnion a);</cell>
-        <cell align="left" valign="middle">Erlang record</cell>
-        <cell align="left" valign="middle">ok = op(Obj, #'myUnion'{label=1, value=66}),</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>enum</em></cell>
-        <cell align="left" valign="middle">enum myEnum {one, two};        <br></br>
-void op(in myEnum a);</cell>
-        <cell align="left" valign="middle">Erlang atom</cell>
-        <cell align="left" valign="middle">ok = op(Obj, one),</cell>
-      </row>
-      <tcaption>OMG IDL constructed types</tcaption>
-    </table>
-
-    <section>
-      <title>Struct Data Type</title>
-      <p>A <c>struct</c> may have Basic, Template, Scoped Names and Constructed 
-        types as members. By using forward declaration we can define a recursive struct:</p>
-      <code type="none"><![CDATA[
-struct myStruct; // Forward declaration
-typedef sequence<myStruct> myStructSeq;
-struct myStruct {
-    myStructSeq chain;
-};
-
-// Deprecated definition (anonymous) not supported by IC
-struct myStruct {
-    sequence<myStruct> chain;
-};
-      ]]></code>
-    </section>
-
-    <section>
-      <title>Enum Data Type</title>
-      <p>The maximum number of identifiers which may defined in an enumeration
-        is 2&sup3;&sup2;. The order in which the identifiers are named in the
-        specification of an enumeration defines the relative order of the
-        identifiers.</p>
-    </section>
-
-    <section>
-      <title>Union Data Type</title>
-      <p>A <c>union</c> may consist of:</p>
-      <list type="bulleted">
-        <item>Identifier</item>
-        <item>Switch - may be an integer, char, boolean, enum or scoped name.</item>
-        <item>Body - with or without a <c>default</c> case; may appear at 
-         most once.</item>
-      </list>
-      <p>A case label must match the defined type of the discriminator, and may only
-        contain a default case if the values given in the non-default labels do
-        not cover the entire range of the union's discriminant type. For example:</p>
-      <code type="none">
-// Illegal default; all cases covered by 
-// non-default cases.
-union BooleanUnion switch(boolean) {
-  case TRUE:  long TrueValue;
-  case FALSE: long FalseValue;
-  default: long DefaultValue; 
-};
-// OK
-union BooleanUnion2 switch(boolean) {
-  case TRUE:  long TrueValue;
-  default: long DefaultValue; 
-};
-      </code>
-      <p>It is not necessary to list all possible values of the union discriminator
-        in the body. Hence, the value of a union is the value of the discriminator
-        and, in given order, one of the following:</p>
-      <list type="ordered">
-        <item>If the discriminator match a label, explicitly listed in a 
-         case statement, the value must be of the same type.</item>
-        <item>If the union contains a default label, the value must match the
-         type of the default label.</item>
-        <item>No value. Orber then inserts the Erlang atom <c>undefined</c>
-         in the value field when receiving a union from an external 
-         ORB.</item>
-      </list>
-      <p>The above can be summed up to:</p>
-      <code type="none">
-// If the discriminator equals 1 or 2 the value 
-// is a long. Otherwise, the atom undefined.
-union LongUnion switch(long) {
-  case 1:
-  case 2:  long TrueValue;
-};
-// If the discriminator equals 1 or 2 the value 
-// is a long. Otherwise, a boolean.
-union LongUnion2 switch(long) {
-  case 1:
-  case 2:  long TrueValue;
-  default: boolean DefaultValue; 
-};
-      </code>
-      <p>In the same way as structs, unions can be recursive if forward
-         declaration is used (anonymous types is deprecated and not supported):</p>
-      <code type="none"><![CDATA[
-// Forward declaration
-union myUnion;
-typedef sequence<myUnion>myUnionSeq;
-union myUnion switch (long) {
-    case 1 : myUnionSeq chain;
-    default: boolean DefaultValue;
-};
-      ]]></code>
-
-    <note>
-      <p>Recursive types (union and struct) require Light IFR. I.e. the
-         IC option {light_ifr, true} is used and that Orber is configured in such a way that
-         Light IFR is activated. Recursive TypeCode is currently not supported, which is
-         why these cannot be encapsulated in an any data type.</p>
-    </note>
-
-    </section>
-    <warning>
-      <p>Every field in, for example, a struct must be initiated. Otherwise
-        it will be set to the atom <c>undefined</c>, which Orber cannot
-        encode when communicating via IIOP. In the example above, invoking
-        the operation with #'myStruct'{a=300} will fail (equal to 
-        #'myStruct'{a=300, b=undefined})</p>
-    </warning>
-    <p>Now we can continue to work on our IDL specification. To begin with, we should
-      determine the return value of the <c>lookup</c> operation. Since the <c>any</c>
-      type can be rather expensive we can use a <c>struct</c> or a <c>union</c> instead.
-      If we intend to return the same information about a employee every time we can
-      use a struct. Let us assume that the DB contains the name, address, employee 
-      number and department.</p>
-    <code type="none"><![CDATA[
-// DB IDL
-#ifndef _DB_IDL_
-#define _DB_IDL_
-module DB {
-
-  typedef unsigned long EmployeeNo;
-
-  enum Department {Department1, Department2};
-
-  struct employee {
-        EmployeeNo No;
-        string Name; 
-        string Address; 
-        Department Dpt;
-  };
-
-  typedef employee EmployeeData;
-
-  interface CommonUser {
-
-     EmployeeData lookup(in EmployeeNo ENo);
-
-  };
-
-  interface Administrator : CommonUser {
-
-     void delete(in EmployeeNo ENo);
-
-  };
-
-  interface Access {
-
-      typedef string<10> UserID;
-      typedef string<10> Password;
-
-      // Since Administrator inherits from CommonUser
-      // the returned Object can be of either type.
-      CommonUser logon(in UserID ID, in Password PW);
-
-  };
-
-};
-#endif    ]]></code>
-    <p>We can also define exceptions (i.e. not system exception) thrown by
-      each interface. Since exceptions are thoroughly described in the chapter
-      <seealso marker="ch_exceptions">System and User Defined Exceptions</seealso>,
-      we choose not to. Hence, we are now ready to compile our IDL-file by 
-      invoking:</p>
-    <pre>
-$ <input>erlc DB.idl</input>
-    </pre>
-    <p>or:</p>
-    <pre>
-$ <input>erl</input>
-Erlang (BEAM) emulator version 5.1.1 [threads:0]
-
-Eshell V5.1.1  (abort with ^G)
-1> <input>ic:gen('DB').</input>
-ok
-2> <input>halt().</input>
-    </pre>
-    <p>The next step is to implement our servers. But, to be able to do that,
-      we need to know how we can access data type definitions. For example,
-      since a struct is mapped to an Erlang record we must include an hrl-file
-      in our callback module.</p>
-  </section>
-
-  <section>
-    <title>Scoped Names and Generated Files</title>
-
-    <section>
-      <title>Scoped Names</title>
-      <p>Within a scope all identifiers must be unique. The following kinds of
-        definitions form scopes in the OMG IDL:</p>
-      <list type="bulleted">
-        <item><em>module</em></item>
-        <item><em>interface</em></item>
-        <item><em>operation</em></item>
-        <item><em>valuetype</em></item>
-        <item><em>struct</em></item>
-        <item><em>union</em></item>
-        <item><em>exception</em></item>
-      </list>
-      <p>For example, since enumerants do not form a scope, the following IDL code
-        is not valid:</p>
-      <code type="none">
-module MyModule {
-     // 'two' is not unique
-     enum MyEnum {one, two};
-     enum MyOtherEnum {two, three};
-};
-      </code>
-      <p>But, since Erlang only has two levels of scope, <em>module</em> and 
-        <em>function</em>, the OMG IDL scope is mapped as follows:</p>
-      <list type="bulleted">
-        <item><em>Function Scope</em> - used for constants, operations and attributes.</item>
-        <item><em>Erlang Module Scope</em> - the Erlang module scope
-         handles the remaining OMG IDL scopes.</item>
-      </list>
-      <p>An Erlang module, corresponding to an IDL global name, is derived by 
-        converting occurrences of "::" to underscore, and eliminating
-        the leading "::". Hence, accessing <c>MyEnum</c> from another module, one 
-        use <c>MyModule::MyEnum</c></p>
-      <p>For example, an operation <c>foo</c> defined in interface <c>I</c>, which
-        is defined in module <c>M</c>, would be written in IDL as <c>M::I::foo</c>
-        and as <c>'M_I':foo</c> in Erlang - <c>foo</c> is the function
-        name and <c>'M_I'</c> is the name of the Erlang module. Applying this
-        knowledge to a stripped version of the DB.idl gives:</p>
-      <code type="none"><![CDATA[
-// DB IDL
-#ifndef _DB_IDL_
-#define _DB_IDL_
-// ++ topmost scope ++ 
-// IC generates oe_XX.erl and oe_XX.hrl.
-// XX is equal to the name of the IDL-file.
-// Tips: create one IDL-file for each top module
-// and give the file the same name (DB.idl).
-// The oe_XX.erl module is used to register data
-// in the IFR.
-module DB {
-
-  // ++ Module scope ++
-  // To access 'EmployeeNo' from another scope, use:
-  // DB::EmployeeNo, DB::Access etc.
-  typedef unsigned long EmployeeNo;
-
-  enum Department {Department1, Department2};
-
-  // Definitions of this struct is contained in:
-  // DB.hrl
-  // Access functions exported by:
-  // DB_employee.erl
-  struct employee {
-     ... CUT ...
-  };
-
-  typedef employee EmployeeData;
-
-  ... CUT ...
-
-  // If this interface should inherit an interface
-  // in another module (e.g. OtherModule) use:
-  // interface Access : OtherModule::OtherInterface
-  interface Access {
-
-      // ++ interface scope ++
-      // Types within this scope is accessible via:
-      // DB::Access::UserID
-      // The Stub/Skeleton for this interface is
-      // placed in the module:
-      // DB_Access.erl
-      typedef string<10> UserID;
-      typedef string<10> Password;
-
-      // Since Administrator inherits from CommonUser
-      // the returned Object can be of either type.
-      // This operation is exported from:
-      // DB_Access.erl
-      CommonUser logon(in UserID ID, in Password PW);
-
-  };
-
-};
-#endif      ]]></code>
-      <p>Using underscores in IDL names can lead to ambiguities
-        due to the name mapping described above. It is advisable to 
-        avoid the use of underscores in identifiers. For example, the following
-        definition would generate two structures named <c>x_y_z</c>.</p>
-      <code type="none">
-module x {
-
-    struct y_z {
-    ...
-    };
-
-    interface y {
-
-    struct z {
-        ...
-    };
-    };
-};
-      </code>
-    </section>
-
-    <section>
-      <title>Generated Files</title>
-      <p>Several files can be generated for each scope.</p>
-      <list type="bulleted">
-        <item>An Erlang source code file (<c>.erl</c>) is generated
-         for top level scope as well as the Erlang header file.</item>
-        <item>An Erlang header file (<c>.hrl</c>) will be generated for 
-         each scope. The header file will contain record definitions 
-         for all <c>struct</c>, <c>union</c> and <c>exception</c> 
-         types in that scope.</item>
-        <item>Modules that contain at least one constant definition,
-         will produce Erlang source code files (<c>.erl</c>).
-         That Erlang file will contain constant functions for 
-         that scope.
-         Modules that contain no constant definitions are considered
-         empty and no code will be produced for them, but only for
-         their included modules/interfaces.</item>
-        <item>Interfaces will produce Erlang source code files (<c>.erl</c>),
-         this code will contain all operation stub code and implementation
-         functions.</item>
-        <item>In addition to the scope-related files, an Erlang source file will
-         be generated for each definition of the types <c>struct</c>,
-        <c>union</c> and <c>exception</c> (these are the types that
-         will be represented in Erlang as records).
-         This file will contain special access functions for that record.</item>
-        <item>The top level scope will produce two files, one header file
-         (<c>.hrl</c>) and one Erlang source file (<c>.erl</c>).
-         These files are named as the IDL file, prefixed with <c>oe_</c>.</item>
-      </list>
-      <p>After compiling DB.idl, the following files have been generated:</p>
-      <list type="bulleted">
-        <item><c>oe_DB.hrl</c> and <c>oe_DB.erl</c> for the top scope level.</item>
-        <item><c>DB.hrl</c> for the module <c>DB</c>.</item>
-        <item><c>DB_Access.hrl</c> and <c>DB_Access.erl</c> for the interface 
-        <c>DB_Access</c>.</item>
-        <item><c>DB_CommonUser.hrl</c> and <c>DB_CommonUser.erl</c> for the interface 
-        <c>DB_CommonUser</c>.</item>
-        <item><c>DB_Administrator.hrl</c> and <c>DB_Administrator.erl</c> for the interface 
-        <c>DB_Administrator</c>.</item>
-        <item><c>DB_employee.erl</c> for the structure <c>employee</c> in module 
-        <c>DB</c>.</item>
-      </list>
-      <p>Since the <c>employee</c> struct is defined in the top level scope,
-        the Erlang record definition is found in <c>DB.hrl</c>. IC also generates
-        stubs/skeletons (e.g. <c>DB_CommonUser.erl</c>) and access functions for
-        some datatypes (e.g. <c>DB_employee.erl</c>). How the stubs/skeletons are
-        used is thoroughly described in
-        <seealso marker="ch_stubs">Stubs/Skeletons</seealso> and
-        <seealso marker="Module_Interface">Module_Interface</seealso>.</p>
-    </section>
-  </section>
-
-  <section>
-    <title>Typecode, Identity and Name Access Functions</title>
-    <p>As mentioned in a previous section, <c>struct</c>, <c>union</c> and 
-      <c>exception</c> types yield record definitions and access code 
-      for that record. 
-      For <c>struct</c>, <c>union</c>, <c>exception</c>, <c>array</c> and 
-      <c>sequence</c> types, a special file is generated that holds access
-      functions for <c>TypeCode</c>, <c>Identity</c> and <c>Name</c>.
-      These functions are put in the file corresponding to the scope where 
-      they are defined. For example, the module <c>DB_employee.erl</c>, 
-      representing the <c>employee</c> struct, exports the following functions:</p>
-    <list type="bulleted">
-      <item>tc/0 - returns the type code for the struct.</item>
-      <item>id/0 - returns the IFR identity of the struct. In this case
-       the returned value is <c>"IDL:DB/employee:1.0"</c>, but
-       if the struct was defined in the scope of <c>CommonUser</c>,
-       the result would be <c>"IDL:DB/CommonUser/employee:1.0"</c>.
-       However, the user usually do not need to know the Id, just
-       which Erlang module contains the correct Id.</item>
-      <item>name/0 - returns the scoped name of the struct. The <c>employee</c>
-       struct name is <c>"DB_employee"</c>.</item>
-    </list>
-    <p><term id="Type Codes"><termdef>Type codes give a complete description  of the type including all its components and structure.</termdef></term>are, for example, used in <seealso marker="any">Any</seealso> values.
-      Hence, we can encapsulate the <c>employee</c> struct in an <c>any</c>
-      type by:</p>
-    <code type="erl">
-%% Erlang code
-....
-AnEmployee = #'DB_employee'{'No'      = 1,
-                            'Name'    = "Adam Ivan Kendall",
-                            'Address' = "Rasunda, Solna",
-                            'Dpt'     = 'Department1'},
-EmployeeTC = 'DB_employee':tc(),
-EmployeeAny = any:create(EmployeeTC, AnEmployee),
-....
-    </code>
-    <p>For more information, see the
-      <seealso marker="#tk_values">Type Code listing</seealso>.</p>
-  </section>
-
-  <section>
-    <title>References to Constants</title>
-    <p>Constants are generated as Erlang functions, and are accessed by a
-      single function call. The functions are put in the file
-      corresponding to the scope where they are defined. There is no
-      need for an object to be started to access a constant.</p>
-    <p>Example:</p>
-    <code type="none">
-// m.idl
-module m {
-    const float pi = 3.14;
-
-    interface i {
-    const float pi = 3.1415;
-    };
-};
-    </code>
-    <p>Since the two constants are defined in different scopes, the IDL code
-      above is valid, but not necessarily a good approach. After compiling
-      <c>m.idl</c>, the constant definitions can be extracted by invoking:</p>
-    <pre>
-$ <input>erlc m.idl</input>
-$ <input>erlc m.erl</input>
-$ <input>erl</input>
-Erlang (BEAM) emulator version 5.1.1 [threads:0]
-
-Eshell V5.1.1  (abort with ^G)
-1> <input>m:pi().</input>
-3.14
-2> <input>m_i:pi().</input>
-3.1415
-3> <input>halt().</input>
-    </pre>
-  </section>
-
-  <section>
-    <title>References to Objects Defined in OMG IDL</title>
-    <p>Objects are accessed by object references. An object reference
-      is an opaque Erlang term created and maintained by the ORB.</p>
-    <p>Objects are implemented by providing implementations for all
-      operations and attributes of the Object, <seealso marker="#op_impl">see operation implementation</seealso>.</p>
-  </section>
-
-  <section>
-    <title>Exceptions</title>
-    <p>Exceptions are handled as Erlang catch and throws. Exceptions
-      are translated to messages over an IIOP bridge but converted
-      back to a throw on the receiving side. Object implementations
-      that invoke operations on other objects must be aware of the
-      possibility of a non-local return. This includes invocation of
-      ORB and IFR services. See also the
-      <seealso marker="ch_exceptions">Exceptions</seealso> section.</p>
-    <p>Exception parameters are mapped as an Erlang record and accessed
-      as such.</p>
-    <p>An object implementation that raises an exception will use the
-      <c>corba:raise/1</c> function, passing the exception record as
-      parameter.</p>
-  </section>
-
-  <section>
-    <title>Access to Attributes</title>
-    <p>Attributes are accessed through their access functions. An
-      attribute implicitly defines the <c>_get</c> and <c>_set</c>
-      operations. These operations are handled in the same way as
-      normal operations. The <c>_get</c> operation is defined as a <c>readonly</c> 
-      attribute.</p>
-    <code type="none">
-readonly attribute long RAttribute;
-attribute long RWAttribute;
-    </code>
-    <p>The <c>RAttribute</c> requires that you implement, in your call-back module,
-      <c>_get_RAttribute</c>. For the <c>RWAttribute</c> it is necessary to implement
-      <c>_get_RWAttribute</c> and <c>_set_RWAttribute</c>.</p>
-  </section>
-
-  <section>
-    <title>Invocations of Operations</title>
-    <marker id="op_impl"></marker>
-    <p>A standard Erlang <c>gen_server</c> behavior is used for
-      object implementation. The <c>gen_server</c> state is then
-      used as the object internal state. Implementation of the object 
-      function is achieved by implementing its methods and attribute operations.
-      These functions will usually have the internal state as their first parameter, 
-      followed by any <c>in</c> and <c>inout</c> parameters. </p>
-    <p>Do not confuse the
-      object internal state with its object reference. The object internal state is
-      an Erlang term which has a format defined by the user.</p>
-    <note>
-      <p>It is not always the case that the internal state will be the first parameter, as stubs can use their own object reference as the first parameter (see the IC documentation).</p>
-    </note>
-    <p>A function call will invoke an operation. The first
-      parameter of the function should be the object reference and then
-      all <c>in</c> and <c>inout</c> parameters follow in the same
-      order as specified in the IDL specification. The result will be a return value
-      unless the function has <c>inout</c> or <c>out</c> parameters specified; 
-      in which case, a tuple of the return value, followed by the parameters will
-      be returned.</p>
-    <p>Example:</p>
-    <code type="none">
-// IDL
-module m {
-  interface i {
-      readonly attribute long RAttribute;
-      attribute long RWAttribute;
-      long foo(in short a);
-      long bar(in char c, inout string s, out long count);
-      void baz(out long Id);
-  };
-};
-    </code>
-    <p>Is used in Erlang as :</p>
-    <code type="none">
-%% Erlang code
-....
-Obj = ...    %% get object reference
-RAttr  = m_i:'_get_RAttribute'(Obj),
-RWAttr = m_i:'_get_RWAttribute'(Obj),
-ok = m_i:'_set_RWAttribute'(Obj, Long),
-R1 = m_i:foo(Obj, 55),
-{R2, S, Count} = m_i:bar(Obj, $a, "hello"),
-....
-    </code>
-    <p>Note how the <c>inout</c> parameter is passed <em>and</em>
-      returned. There is no way to use a single occurrence of a
-      variable for this in Erlang. Also note, that <c>ok</c>, Orber's 
-      representation of the IDL-type <c>void</c>, must be returned by
-      <c>baz</c> and <c>'_set_RWAttribute'</c>. 
-      These operations can be implemented in the call-back module as:</p>
-    <code type="erl">
-'_set_RWAttribute'(State, Long) ->
-    {reply, ok, State}.
-
-'_get_RWAttribute'(State) ->
-    {reply, Long, State}.
-
-'_get_RAttribute'(State) ->
-    {reply, Long, State}.
-
-foo(State, AShort) ->
-    {reply, ALong, State}.
- 
-bar(State, AShort, AString) ->
-    {reply, {ALong, "MyString", ALong}, State}.
- 
-baz(State) ->
-    {reply, {ok, AId}, State}.
-    </code>
-    <p>The operations may require more arguments (depends on IC options used). For
-      more information, see <seealso marker="ch_stubs">Stubs/Skeletons</seealso>
-      and <seealso marker="Module_Interface">Module_Interface</seealso>.</p>
-    <warning>
-      <p>A function can also be defined to be <c>oneway</c>, i.e. 
-        asynchronous. But, since the behavior of a oneway operation is not
-        defined in the OMG specifications (i.e. the behavior can differ depending on
-        which other ORB Orber is communicating with), one should avoid using it.</p>
-    </warning>
-  </section>
-
-  <section>
-    <title>Implementing the DB Application</title>
-    <p>Now we are ready to implement the call-back modules. There are three modules
-      we must create:</p>
-    <list type="bulleted">
-      <item>DB_Access_impl.erl</item>
-      <item>DB_CommonUser_impl.erl</item>
-      <item>DB_Administrator_impl.erl</item>
-    </list>
-    <p>An easy way to accomplish that, is to use the IC backend <c>erl_template</c>,
-      which will generate a complete call-back module. One should also add
-      the same compile options, for example <c>this</c> or <c>from</c>,
-      used when generating the stub/skeleton modules:</p>
-    <code type="none">
-$> erlc +"{be,erl_template}" DB.idl
-    </code>
-    <p>We begin with implementing the <c>DB_Access_impl.erl</c> module, which,
-      if we used <c>erl_template</c>, will look like the following. All we need
-      to do is to add the logic to the <c>logon</c> operation.</p>
-    <code type="erl"><![CDATA[
-%%----------------------------------------------------------------------
-%% <LICENSE>
-%% 
-%%     $Id$
-%%
-%%----------------------------------------------------------------------
-%% Module       : DB_Access_impl.erl
-%% 
-%% Source       : /home/user/example/DB.idl
-%% 
-%% Description  : 
-%% 
-%% Creation date: 2005-05-20
-%%
-%%----------------------------------------------------------------------
--module('DB_Access_impl').
-
--export([logon/3]).
-
-%%----------------------------------------------------------------------
-%% Internal Exports
-%%----------------------------------------------------------------------
--export([init/1,
-         terminate/2,
-         code_change/3,
-         handle_info/2]).
-
-%%----------------------------------------------------------------------
-%% Include Files
-%%----------------------------------------------------------------------
-
-
-%%----------------------------------------------------------------------
-%% Macros
-%%----------------------------------------------------------------------
-
-
-%%----------------------------------------------------------------------
-%% Records
-%%----------------------------------------------------------------------
--record(state, {}).
-
-%%======================================================================
-%% API Functions
-%%======================================================================
-%%----------------------------------------------------------------------
-%% Function   : logon/3
-%% Arguments  : State - term()
-%%              ID = String()
-%%              PW = String()
-%% Returns    : ReturnValue = OE_Reply
-%%              OE_Reply = Object_Ref()
-%% Raises     : 
-%% Description: 
-%%----------------------------------------------------------------------
-logon(State, ID, PW) ->
-    %% Check if the ID/PW is valid and what 
-    %% type of user it is (Common or Administrator).
-    OE_Reply
-            = case check_user(ID, PW) of
-             {ok, administrator} ->
-                'DB_Administrator':oe_create();
-             {ok, common} ->
-                'DB_CommonUser':oe_create();
-             error ->
-                %% Here we should throw an exception              
-                corba:raise(....)
-        end,
-    {reply, OE_Reply, State}.
-
-%%======================================================================
-%% Internal Functions
-%%======================================================================
-%%----------------------------------------------------------------------
-%% Function   : init/1
-%% Arguments  : Env = term()
-%% Returns    : {ok, State}          |
-%%              {ok, State, Timeout} |
-%%              ignore               |
-%%              {stop, Reason}
-%% Raises     : -
-%% Description: Initiates the server
-%%----------------------------------------------------------------------
-init(_Env) ->
-    {ok, #state{}}.
-
-
-%%----------------------------------------------------------------------
-%% Function   : terminate/2
-%% Arguments  : Reason = normal | shutdown | term()
-%%              State = term()
-%% Returns    : ok
-%% Raises     : -
-%% Description: Invoked when the object is terminating.
-%%----------------------------------------------------------------------
-terminate(_Reason, _State) ->
-    ok.
-
-
-%%----------------------------------------------------------------------
-%% Function   : code_change/3
-%% Arguments  : OldVsn = undefined | term()
-%%              State = NewState = term()
-%%              Extra = term()
-%% Returns    : {ok, NewState}
-%% Raises     : -
-%% Description: Invoked when the object should update its internal state
-%%              due to code replacement.
-%%----------------------------------------------------------------------
-code_change(_OldVsn, State, _Extra) ->
-    {ok, State}.
-
-
-%%----------------------------------------------------------------------
-%% Function   : handle_info/2
-%% Arguments  : Info = normal | shutdown | term()
-%%              State = NewState = term()
-%% Returns    : {noreply, NewState}          |
-%%              {noreply, NewState, Timeout} |
-%%              {stop, Reason, NewState}
-%% Raises     : -
-%% Description: Invoked when, for example, the server traps exits.
-%%----------------------------------------------------------------------
-handle_info(_Info, State) ->
-    {noreply, State}.
-    ]]></code>
-    <p>Since <c>DB_Administrator</c> inherits from <c>DB_CommonUser</c>,
-      we must implement <c>delete</c> in the <c>DB_Administrator_impl.erl</c>
-      module, and <c>lookup</c> in <c>DB_Administrator_impl.erl</c><em>and</em><c>DB_CommonUser_impl.erl</c>. But wait, is that really necessary? Actually,
-      it is not. We simple use the IC compile option <em>impl</em>:</p>
-    <pre>
-$ <input>erlc +'{{impl, "DB::CommonUser"}, "DBUser_impl"}'\
- +'{{impl, "DB::Administrator"}, "DBUser_impl"}' DB.idl</input>
-$ <input>erlc *.erl</input>
-    </pre>
-    <p>Instead of creating, and not the least, maintaining two call-back modules,
-      we only have to deal with <c>DBUser_impl.erl</c>. If we generated the
-      templates, we simply rename <c>DB_Administrator_impl.erl</c> to
-      <c>DBUser_impl.erl</c>. See also the
-      <seealso marker="ch_exceptions">Exceptions</seealso> chapter.
-      In the following example, only the implementation of the API functions
-      are shown:</p>
-    <code type="erl">
-%%======================================================================
-%% API Functions
-%%======================================================================
-%%----------------------------------------------------------------------
-%% Function   : delete/2
-%% Arguments  : State - term()
-%%              ENo = unsigned_Long()
-%% Returns    : ReturnValue = ok
-%% Raises     : 
-%% Description: 
-%%----------------------------------------------------------------------
-delete(State, ENo) ->
-        %% How we access the DB, for example mnesia, is not shown here.
-        case delete_employee(No) of
-            ok ->
-                {reply, ok, State};
-            error ->
-                %% Here we should throw an exception if
-                %% there is no match.
-                corba:raise(....)
-        end.
-
-%%----------------------------------------------------------------------
-%% Function   : lookup/2
-%% Arguments  : State - term()
-%%              ENo = unsigned_Long()
-%% Returns    : ReturnValue = OE_Reply
-%%              OE_Reply = #'DB_employee'{No,Name,Address,Dpt}
-%%              No = unsigned_Long()
-%%              Name = String()
-%%              Address = String()
-%%              Dpt = Department
-%%              Department = 'Department1' | 'Department2' 
-%% Raises     : 
-%% Description: 
-%%----------------------------------------------------------------------
-lookup(State, ENo) ->
-        %% How we access the DB, for example mnesia, is not shown here.
-        case lookup_employee(ENo) of
-            %% We assume that we receive a 'DB_employee' struct
-            {ok, Employee} ->
-                OE_Reply = Employee,
-                {reply, OE_Reply, State};
-            error ->
-                %% Here we should throw an exception if
-                %% there is no match.
-                corba:raise(....)
-        end.
-    </code>
-    <p>After you have compiled both call-back modules, and implemented the missing
-      functionality (e.g. lookup_employee/1), we can test our application:</p>
-    <code type="none">
-%% Erlang code
-....
-%% Create an Access object
-Acc = 'DB_Access':oe_create(),
-
-%% Login is Common user and Administrator
-Adm = 'DB_Access':logon(A, "admin", "pw"),
-Com = 'DB_Access':logon(A, "comm", "pw"),
-
-%% Lookup existing employee
-Employee = 'DB_Administrator':lookup(Adm, 1),
-Employee = 'DB_CommonUser':lookup(Adm, 1),
-
-%% If we try the same using the DB_CommonUser interface 
-%% it result in an exit since that operation is not exported.
-{'EXIT', _} = (catch 'DB_CommonUser':delete(Adm, 1)),
-
-%% Try to delete the employee via the CommonUser Object
-{'EXCEPTION', _} = (catch 'DB_Administrator':delete(Com, 1)),
-
-%% Invoke delete operation on the Administrator object
-ok = 'DB_Administrator':delete(Adm, 1),
-....
-    </code>
-  </section>
-
-  <section>
-    <title>Reserved Compiler Names and Keywords</title>
-    <marker id="key_words"></marker>
-    <p>The use of some names is  strongly discouraged due to 
-      ambiguities. However, the use of some names is prohibited 
-      when using the Erlang mapping , as they are strictly reserved for IC.</p>
-    <p>IC reserves all identifiers starting with <c>OE_</c> and <c>oe_</c> 
-      for internal use.</p>
-    <p>Note also, that an identifier in IDL can  contain alphabetic,
-      digits and underscore characters, but the first character 
-      <em>must</em> be alphabetic.
-      </p>
-    <p>The OMG defines a set of reserved words, shown below, for use as keywords. 
-      These may <em>not</em> be used as, for example, identifiers. The keywords
-      which are not in bold face was introduced in the OMG CORBA-3.0 
-      specification.</p>
-    <table>
-      <row>
-        <cell align="left" valign="middle"><em>abstract</em></cell>
-        <cell align="left" valign="middle"><em>exception</em></cell>
-        <cell align="left" valign="middle"><em>inout</em></cell>
-        <cell align="left" valign="middle">provides</cell>
-        <cell align="left" valign="middle"><em>truncatable</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>any</em></cell>
-        <cell align="left" valign="middle">emits</cell>
-        <cell align="left" valign="middle"><em>interface</em></cell>
-        <cell align="left" valign="middle"><em>public</em></cell>
-        <cell align="left" valign="middle"><em>typedef</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>attribute</em></cell>
-        <cell align="left" valign="middle"><em>enum</em></cell>
-        <cell align="left" valign="middle"><em>local</em></cell>
-        <cell align="left" valign="middle">publishes</cell>
-        <cell align="left" valign="middle">typeid</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>boolean</em></cell>
-        <cell align="left" valign="middle">eventtype</cell>
-        <cell align="left" valign="middle"><em>long</em></cell>
-        <cell align="left" valign="middle"><em>raises</em></cell>
-        <cell align="left" valign="middle">typeprefix</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>case</em></cell>
-        <cell align="left" valign="middle"><em>factory</em></cell>
-        <cell align="left" valign="middle"><em>module</em></cell>
-        <cell align="left" valign="middle"><em>readonly</em></cell>
-        <cell align="left" valign="middle"><em>unsigned</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>char</em></cell>
-        <cell align="left" valign="middle"><em>FALSE</em></cell>
-        <cell align="left" valign="middle">multiple</cell>
-        <cell align="left" valign="middle">setraises</cell>
-        <cell align="left" valign="middle"><em>union</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">component</cell>
-        <cell align="left" valign="middle">finder</cell>
-        <cell align="left" valign="middle"><em>native</em></cell>
-        <cell align="left" valign="middle"><em>sequence</em></cell>
-        <cell align="left" valign="middle">uses</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>const</em></cell>
-        <cell align="left" valign="middle"><em>fixed</em></cell>
-        <cell align="left" valign="middle"><em>Object</em></cell>
-        <cell align="left" valign="middle"><em>short</em></cell>
-        <cell align="left" valign="middle"><em>ValueBase</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">consumes</cell>
-        <cell align="left" valign="middle"><em>float</em></cell>
-        <cell align="left" valign="middle"><em>octet</em></cell>
-        <cell align="left" valign="middle"><em>string</em></cell>
-        <cell align="left" valign="middle"><em>valuetype</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>context</em></cell>
-        <cell align="left" valign="middle">getraises</cell>
-        <cell align="left" valign="middle"><em>oneway</em></cell>
-        <cell align="left" valign="middle"><em>struct</em></cell>
-        <cell align="left" valign="middle"><em>void</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>custom</em></cell>
-        <cell align="left" valign="middle">home</cell>
-        <cell align="left" valign="middle"><em>out</em></cell>
-        <cell align="left" valign="middle"><em>supports</em></cell>
-        <cell align="left" valign="middle"><em>wchar</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>default</em></cell>
-        <cell align="left" valign="middle">import</cell>
-        <cell align="left" valign="middle">primarykey</cell>
-        <cell align="left" valign="middle"><em>switch</em></cell>
-        <cell align="left" valign="middle"><em>wstring</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle"><em>double</em></cell>
-        <cell align="left" valign="middle"><em>in</em></cell>
-        <cell align="left" valign="middle"><em>private</em></cell>
-        <cell align="left" valign="middle"><em>TRUE</em></cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <tcaption>OMG IDL keywords</tcaption>
-    </table>
-    <p>The keywords listed above must be written exactly as shown. Any usage
-      of identifiers that collide with a keyword is illegal. For example,
-      <em>long</em> is a valid keyword; <em>Long</em> and <em>LONG</em> are
-      illegal as keywords and identifiers. But, since the OMG must be able
-      to expand the IDL grammar, it is possible to use <em>Escaped  Identifiers</em>. For example, it is not unlikely that <c>native</c>
-      have been used in IDL-specifications as identifiers. One option is to
-      change all occurrences to <c>myNative</c>. Usually, it is necessary
-      to change programming language code that depends upon that IDL as well.
-      Since Escaped Identifiers just disable type checking (i.e. if it is a reserved
-      word or not) and leaves everything else unchanged, it is only necessary to
-      update the IDL-specification. To escape an identifier, simply prefix it
-      with <em>_</em>. The following IDL-code is illegal:</p>
-    <code type="none">
-typedef string native;
-interface i {
-   void foo(in native Arg);
-   };
-};
-    </code>
-    <p>With Escaped Identifiers the code will look like:</p>
-    <code type="none">
-typedef string _native;
-interface i {
-   void foo(in _native Arg);
-   };
-};
-    </code>
-  </section>
-
-  <section>
-    <title>Type Code Representation</title>
-    <marker id="tk_values"></marker>
-    <p>Type Codes are used in <c>any</c> values. To avoid mistakes, you should
-      use access functions exported by the Data Types modules
-      (e.g. struct, union etc) or the <seealso marker="orber_tc">orber_tc</seealso>
-      module.</p>
-    <table>
-      <row>
-        <cell align="left" valign="middle"><em>Type Code</em></cell>
-        <cell align="left" valign="middle"><em>Example</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_null</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_void</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_short</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_long</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_longlong</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_ushort</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_ulong</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_ulonglong</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_float</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_double</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_boolean</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_char</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_wchar</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_octet</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_any</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_TypeCode</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">tk_Principal</cell>
-        <cell align="left" valign="middle"></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">{tk_objref, IFRId, Name}</cell>
-        <cell align="left" valign="middle">{tk_objref, "IDL:M1\I1:1.0", "I1"}</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">{tk_struct, IFRId, Name, [{ElemName, ElemTC}]}</cell>
-        <cell align="left" valign="middle">{tk_struct, "IDL:M1\S1:1.0", "S1", [{"a", tk_long}, {"b", tk_char}]}</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">{tk_union, IFRId, Name, DiscrTC, DefaultNr, [{Label, ElemName, ElemTC}]}         <br></br>
-Note: DefaultNr tells which of tuples in the case list that is default, or -1 if no default</cell>
-        <cell align="left" valign="middle">{tk_union, "IDL:U1:1.0", "U1", tk_long, 1, [{1, "a", tk_long}, {default, "b", tk_char}]}</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">{tk_enum, IFRId, Name, [ElemName]}</cell>
-        <cell align="left" valign="middle">{tk_enum, "IDL:E1:1.0", "E1", ["a1", "a2"]}</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">{tk_string, Length}</cell>
-        <cell align="left" valign="middle">{tk_string, 5}</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">{tk_wstring, Length}</cell>
-        <cell align="left" valign="middle">{tk_wstring, 7}</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">{tk_fixed, Digits, Scale}</cell>
-        <cell align="left" valign="middle">{tk_fixed, 3, 2}</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">{tk_sequence, ElemTC, Length}</cell>
-        <cell align="left" valign="middle">{tk_sequence, tk_long, 4}</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">{tk_array, ElemTC, Length}</cell>
-        <cell align="left" valign="middle">{tk_array, tk_char, 9}</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">{tk_alias, IFRId, Name, TC}</cell>
-        <cell align="left" valign="middle">{tk_alias, "IDL:T1:1.0", "T1", tk_short}</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">{tk_except, IFRId, Name, [{ElemName, ElemTC}]}</cell>
-        <cell align="left" valign="middle">{tk_except, "IDL:Exc1:1.0", "Exc1", [{"a", tk_long}, {"b", {tk_string, 0}}]}</cell>
-      </row>
-      <tcaption>Type Code tuples</tcaption>
-    </table>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_ifr.xml b/lib/orber/doc/src/ch_ifr.xml
deleted file mode 100644
index 09302ab6cc..0000000000
--- a/lib/orber/doc/src/ch_ifr.xml
+++ /dev/null
@@ -1,50 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>1999</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>Interface Repository</title>
-    <prepared></prepared>
-    <docno></docno>
-    <date>1998-10-10</date>
-    <rev></rev>
-    <file>ch_ifr.xml</file>
-  </header>
-
-  <section>
-    <title>Interface Repository(IFR)</title>
-    <p>The IFR is an interface repository built on the Mnesia
-      application. Orber uses the  IFR for some type-checking
-      when coding/decoding IIOP. The IFR is capable of storing all
-      interfaces and declarations of OMG IDL.
-      </p>
-    <p>The interface repository is mainly used for dynamical
-      interfaces, and as none are currently supported this function
-      is only really used for retrieving information about interfaces.</p>
-    <p>Functions relating to the manipulation of the IFR including,
-      initialization of the IFR, as well as, locating, creating and
-      destroying initial references are detailed further in the Manual
-      Pages.
-      </p>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_install.xml b/lib/orber/doc/src/ch_install.xml
deleted file mode 100644
index 65faa91ccf..0000000000
--- a/lib/orber/doc/src/ch_install.xml
+++ /dev/null
@@ -1,1001 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>1997</year><year>2017</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-
-    </legalnotice>
-
-    <title>Installing Orber</title>
-    <prepared></prepared>
-    <responsible></responsible>
-    <docno></docno>
-    <approved></approved>
-    <checked></checked>
-    <date>1998-09-28</date>
-    <rev></rev>
-    <file>ch_install.xml</file>
-  </header>
-
-  <section>
-    <title>Installation Process </title>
-    <p>This chapter describes how to install Orber in an Erlang
-      Environment.</p>
-
-    <section>
-      <title>Preparation</title>
-      <p>To begin with, you must decide if you want to run Orber as a:</p>
-      <list type="bulleted">
-        <item><em>Single node (non-distributed)</em> - all communication with other
-         Orber instances and ORB's supplied by other vendors use the OMG
-         GIOP protocol.</item>
-        <item><em>Multi node (distributed)</em> - all Orber nodes, within the same
-        <c>domain</c>, communicate via the Erlang distribution protocol.
-         For all other Orber instances, i.e. not part of the same <c>domain</c>,
-         and ORB's supplied by other vendors, the OMG GIOP protocol
-         is used.</item>
-      </list>
-      <p>Which approach to use is highly implementation specific, but a few
-        things you should consider:</p>
-      <list type="bulleted">
-        <item>All nodes within an Orber domain should have the same
-         security level.</item>
-        <item>If the capacity is greater than load (volume of traffic)
-         a single-node Orber might be a good solution.</item>
-        <item>In some cases the distributed system architecture requires a
-         single-node <term id="Orber installation"><termdef>is the structure of the ORB or ORBs as defined during the install process is called the "installation".</termdef></term>.</item>
-        <item>A multi-node Orber makes it possible to load balance
-         and create a more fault tolerant system. The Objects
-         can also have a uniform view if you use distributed
-         Mnesia tables.</item>
-        <item>Since the GIOP protocol creates a larger overhead than the
-         Erlang distribution protocol, the performance will be better
-         when communicating with Objects within the same Orber domain
-         compared with inter ORB communication (GIOP).</item>
-      </list>
-      <p>You also have to decide if you want Orber to store internal data using
-        <c>disc_copies</c> and/or <c>ram_copies</c>. Which storage type you should
-        depends if/how you intend to use Mnesia in your application. If you
-        intend to use <c>disc_copies</c> you must start with creating a Mnesia
-        schema, which contain information about the location of the Erlang nodes
-        where Orber is planned to be run. For more background information, 
-        see the Mnesia documentation.</p>
-      <p>In some cases it is absolutely necessary to change the default configuration
-        of Orber. For example, if two Orber-ORB's shall be able to communicate
-        via GIOP, they must have a unique <c>domain</c> domain. Consult the
-        <seealso marker="ch_install#config">configuration settings</seealso>
-        section. If  you encounter any problems; see the chapter about 
-        <em>Debugging</em> in this User's Guide.</p>
-    </section>
-
-    <section>
-      <title>Jump Start Orber</title>
-      <p>The easiest way to start Orber is to use <c>orber:jump_start(Port)</c>,
-        which start a single-node ORB with (most likely) a unique
-        domain (i.e. "IP-number:Port"). This function may only be used
-        during development and testing. For any other situation, install and
-        start Orber as described in the following sections.
-        The listen port, i.e. iiop_port configuration parameter, is set to
-        the supplied Port.</p>
-      <warning>
-        <p>How Orber is configured when using <c>orber:jump_start(Port)</c>
-          may change at any time without warning. Hence, this operation must
-          not be used in systems delivered to a customer.</p>
-      </warning>
-    </section>
-
-    <section>
-      <title>Install Single Node Orber</title>
-      <p>Since a single node Orber communicate via the OMG GIOP protocol it is not
-        necessary to start the Erlang distribution (i.e. using <c>-name/-sname</c>).</p>
-      <p>If we use <c>ram_copies</c> there is no need for creating a disk based
-        schema. Simply use:</p>
-      <code type="erl">
-erl> mnesia:start().
-erl> corba:orb_init([{domain, "MyRAMSingleNodeORB"}]).
-erl> orber:install([node()], [{ifr_storage_type, ram_copies}]).
-erl> orber:start().
-      </code>
-      <p>If you installation requires <c>disc_copies</c> you must begin with
-        creating a Mnesia schema. Otherwise, the installation is similar
-        to a RAM installation:</p>
-      <code type="erl">
-erl> mnesia:create_schema([node()]).
-erl> mnesia:start().
-erl> corba:orb_init([{domain, "MyDiskSingleNodeORB"}]).
-erl> orber:install([node()], [{ifr_storage_type, disc_copies},
-                              {nameservice_storage_type, disc_copies}]).
-erl> orber:start().
-      </code>
-      <p>You can still choose to store the IFR data as ram_copies, but then
-        the data must be re-installed (i.e. invoke <c>orber:install/2</c>)
-        if the node is restarted. Hence, since the IFR data is rather static
-        you should use <c>disc_copies</c>. For more information see the
-        <c>orber</c> section in the reference manual.</p>
-      <p>If you do not need to change Orber's configuration you can skip
-        <seealso marker="corba">orb_init/1</seealso>. 
-        But, you <em>should</em> at least set the IIOP timeout parameters.</p>
-    </section>
-
-    <section>
-      <title>Install RAM Based Multi Node Orber</title>
-      <p>Within a domain Orber uses the Erlang distribution protocol. Hence, you
-        <em>must</em> start it first by, for example, using:</p>
-      <code type="erl">
-hostA> erl -sname nodeA
-      </code>
-      <p>In this example, we assume that we want to use two nodes; <c>nodeA</c> and
-        <c>nodeB</c>. Since Mnesia must know which other nodes should a part
-        of the distribution we either need to add the Mnesia configuration
-        parameter <c>extra_db_nodes</c> or use <c>mnesia:change_config/2</c>. To 
-        begin with, Mnesia must be started on all nodes before we can install
-        Orber:</p>
-      <code type="erl">
-nodeA@hostA> mnesia:start().
-nodeA@hostA> mnesia:change_config(extra_db_nodes, 
-                                  [nodeA@hostA, nodeB@hostB]).
-      </code>
-      <p>After that the above have been repeated on <c>nodeB</c> we must
-        first make sure that both nodes will use the same domain name, then
-        we can install Orber:</p>
-      <code type="erl">
-nodeA@hostA> corba:orb_init([{domain, "MyRAMMultiNodeORB"}]).
-nodeA@hostA> orber:install([nodeA@hostA, nodeB@hostB],
-                           [{ifr_storage_type, ram_copies}]).
-nodeA@hostA> orber:start().
-      </code>
-      <p>Note that you can only invoke <c>orber:install/1/2</c> on one of the
-        nodes. Now we can start Orber on the other node:</p>
-      <code type="erl">
-nodeB@hostB> corba:orb_init([{domain, "MyRAMMultiNodeORB"}]).
-nodeB@hostB> orber:start().
-      </code>
-    </section>
-
-    <section>
-      <title>Install Disk Based Multi Node Orber</title>
-      <p>As for RAM based multi-node Orber installations, the Erlang distribution
-        must be started (e.g. erl -sname nodeA). The major difference is that
-        when it is disk based a Mnesia schema must be created:</p>
-      <code type="erl">
-nodeA@hostA> mnesia:create_schema([nodeA@hostA, nodeB@hostB]).
-nodeA@hostA> mnesia:start().
-      </code>
-      <p>In this example, we assume that we want to use two nodes; <c>nodeA</c> and
-        <c>nodeB</c>. Since it is not possible to create a schema on more than 
-        one node. Hence, all we have to do is to start Mnesia (i.e. invoke 
-        <c>mnesia:start()</c>) on <c>nodeB</c>.</p>
-      <p>After Mnesia have been started on all nodes, you must confirm that all 
-        nodes have the same domain name, then Orber is ready to be installed:</p>
-      <code type="erl">
-nodeA@hostA> corba:orb_init([{domain, "MyDiskMultiNodeORB"}]).
-nodeA@hostA> orber:install([nodeA@hostA, nodeB@hostB],
-                           [{ifr_storage_type, disc_copies}]).
-nodeA@hostA> orber:start().
-      </code>
-      <p>Note that you can only invoke <c>orber:install/1/2</c> on one of the
-        nodes. Now we can start Orber on the other node:</p>
-      <code type="erl">
-nodeB@hostB> corba:orb_init([{domain, "MyDiskMultiNodeORB"}]).
-nodeB@hostB> orber:start().
-      </code>
-    </section>
-
-  </section>
-
-  <section>
-    <title>Configuration</title>
-    <marker id="config"></marker>
-    <p>It is essential that one configure Orber properly, to avoid, for example,
-      malicious attacks and automatically terminate IIOP connections no longer
-      in use. An easy way to extract information about Orber's configuration
-      parameters is to invoke the operation
-      <seealso marker="orber">orber:info/1/2</seealso>.
-      Orber offer the following configuration parameters:</p>
-    <table>
-      <row>
-        <cell align="center" valign="middle"><em>Key</em></cell>
-        <cell align="center" valign="middle"><em>Range</em></cell>
-        <cell align="center" valign="middle"><em>Default</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">domain</cell>
-        <cell align="left" valign="middle">string()</cell>
-        <cell align="left" valign="middle">"ORBER"</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_port</cell>
-        <cell align="left" valign="middle">integer() >= 0</cell>
-        <cell align="left" valign="middle">4001</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">nat_iiop_port</cell>
-        <cell align="left" valign="middle">integer() > 0 | {local, integer(), [{integer(), integer()}]}</cell>
-        <cell align="left" valign="middle">The same as <c>iiop_port</c></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_out_ports</cell>
-        <cell align="left" valign="middle">0 | {integer(),integer()}</cell>
-        <cell align="left" valign="middle">0</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_out_ports_attempts</cell>
-        <cell align="left" valign="middle">integer() > 0</cell>
-        <cell align="left" valign="middle">1</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_out_ports_random</cell>
-        <cell align="left" valign="middle">true | false</cell>
-        <cell align="left" valign="middle">false</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_max_fragments</cell>
-        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
-        <cell align="left" valign="middle">infinity</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_max_in_requests</cell>
-        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
-        <cell align="left" valign="middle">infinity</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_max_in_connections</cell>
-        <cell align="left" valign="middle">integer() > 0</cell>
-        <cell align="left" valign="middle">infinity</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_backlog</cell>
-        <cell align="left" valign="middle">integer() > 0</cell>
-        <cell align="left" valign="middle">5</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_packet_size</cell>
-        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
-        <cell align="left" valign="middle">infinity</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">ip_address</cell>
-        <cell align="left" valign="middle">string() | {multiple, [string()]}</cell>
-        <cell align="left" valign="middle">All interfaces</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">ip_address_local</cell>
-        <cell align="left" valign="middle">string()</cell>
-        <cell align="left" valign="middle">Defined by the underlying system</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">nat_ip_address</cell>
-        <cell align="left" valign="middle">string() | {multiple, [string()]} |  {local, string(), [{string(), string()}]}</cell>
-        <cell align="left" valign="middle">The same as <c>ip_address</c></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">objectkeys_gc_time</cell>
-        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
-        <cell align="left" valign="middle">infinity</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">giop_version</cell>
-        <cell align="left" valign="middle">{1,0} | {1,1} | {1,2}</cell>
-        <cell align="left" valign="middle">{1,1}</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_setup_connection_timeout</cell>
-        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
-        <cell align="left" valign="middle">infinity</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_connection_timeout</cell>
-        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
-        <cell align="left" valign="middle">infinity</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_in_connection_timeout</cell>
-        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
-        <cell align="left" valign="middle">infinity</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_out_keepalive</cell>
-        <cell align="left" valign="middle">true | false</cell>
-        <cell align="left" valign="middle">false</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_in_keepalive</cell>
-        <cell align="left" valign="middle">true | false</cell>
-        <cell align="left" valign="middle">false</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_timeout</cell>
-        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
-        <cell align="left" valign="middle">infinity</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">interceptors</cell>
-        <cell align="left" valign="middle">{native, [atom()]}</cell>
-        <cell align="left" valign="middle">-</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">local_interceptors</cell>
-        <cell align="left" valign="middle">{native, [atom()]}</cell>
-        <cell align="left" valign="middle">-</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">orbInitRef</cell>
-        <cell align="left" valign="middle">[string()] | undefined</cell>
-        <cell align="left" valign="middle">undefined</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">orbDefaultInitRef</cell>
-        <cell align="left" valign="middle">string() | undefined</cell>
-        <cell align="left" valign="middle">undefined</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">orber_debug_level</cell>
-        <cell align="left" valign="middle">0 - 10</cell>
-        <cell align="left" valign="middle">0</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">flags</cell>
-        <cell align="left" valign="middle">integer() >= 0</cell>
-        <cell align="left" valign="middle">0</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_acl</cell>
-        <cell align="left" valign="middle">[{atom(), string()}] | [{atom(), string(), [string()]}]</cell>
-        <cell align="left" valign="middle">[]</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">secure</cell>
-        <cell align="left" valign="middle">no | ssl</cell>
-        <cell align="left" valign="middle">no</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">ssl_generation</cell>
-        <cell align="left" valign="middle">2 | 3</cell>
-        <cell align="left" valign="middle">2</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_ssl_port</cell>
-        <cell align="left" valign="middle">integer() >= 0</cell>
-        <cell align="left" valign="middle">4002</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_ssl_accept_timeout</cell>
-        <cell align="left" valign="middle">integer() > 0 | infinity</cell>
-        <cell align="left" valign="middle">infinity</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_ssl_backlog</cell>
-        <cell align="left" valign="middle">integer() > 0</cell>
-        <cell align="left" valign="middle">5</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_ssl_ip_address_local</cell>
-        <cell align="left" valign="middle">string()</cell>
-        <cell align="left" valign="middle">Defined by the underlying system</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">nat_iiop_ssl_port</cell>
-        <cell align="left" valign="middle">integer() > 0 | {local, integer(), [{integer(), integer()}]}</cell>
-        <cell align="left" valign="middle">The same as <c>iiop_ssl_port</c></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">ssl_server_options</cell>
-        <cell align="left" valign="middle">list()</cell>
-        <cell align="left" valign="middle">See the <seealso marker="ssl:ssl">SSL application</seealso> 
-	for valid options.</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">ssl_client_options</cell>
-        <cell align="left" valign="middle">list()</cell>
-        <cell align="left" valign="middle">See the <seealso marker="ssl:ssl">SSL application</seealso> 
-	for valid options.</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_ssl_out_keepalive</cell>
-        <cell align="left" valign="middle">true | false</cell>
-        <cell align="left" valign="middle">false</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">iiop_ssl_in_keepalive</cell>
-        <cell align="left" valign="middle">true | false</cell>
-        <cell align="left" valign="middle">false</cell>
-      </row>
-      <tcaption>Orber Configuration Parameters</tcaption>
-    </table>
-    <br></br>
-    <br></br>
-    <p><em>Comments on the table 'Orber Configuration Parameters':</em></p>
-    <taglist>
-      <tag><em>domain</em></tag>
-      <item>Since Orber domains, they are supposed to communicate via IIOP,
-      <em>MUST</em> have unique names, communication will
-       fail if two domains have the same name. The domain name <em>MAY NOT</em>
-       contain <c>^G</c> (i.e. <c>\007</c>).</item>
-      <tag><em>iiop_port</em></tag>
-      <item>If set to 0 the OS will pick any vacant port. 
-            <br></br>
-<em>Note:</em>On a UNIX system it is preferable to
-       have a IIOP port higher than 1023, since it is not recommended to 
-       run Erlang as a root user.</item>
-      <tag><em>nat_iiop_port</em></tag>
-      <item>The value is either an integer or <c>{local, DefaultNATPort, [{Port, NATPort}]}</c>. See also
-      <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item>
-      <tag><em>iiop_out_ports</em></tag>
-      <item>When set to 0 any available port will be used. 
-       If a range is specified, Orber will only
-       use the local ports within the interval when trying to connect to
-       another ORB (Orber acts as a client ORB). If all ports are in use
-       communication will fail. Hence, it is <em>absolutely necessary</em> to
-       set <c>iiop_connection_timeout</c> as well. Otherwise, connections
-       no longer in use will block further communication. If one use, for
-       example, <c>erl -orber iiop_out_ports "{5000,5020}"</c>, Orber
-       will only use port 5000 to 5020 when connecting.
-       If communicating via SSL, make sure you use a version that supports
-       the local <c>{port, Port}</c> option. See also
-      <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item>
-      <tag><em>iiop_out_ports_random</em></tag>
-      <item>Requires that <c>iiop_out_ports</c> define a port range. If that is the
-       case Orber will select a port randomly from that sequence.</item>
-      <tag><em>iiop_out_ports_attempts</em></tag>
-      <item>Requires that <c>iiop_out_ports</c> define a port range. If so Orber will
-       accept a number of timeouts, defined by this parameter, when trying to connect
-       to another ORB.</item>
-      <tag><em>iiop_max_fragments</em></tag>
-      <item>Limits the number of IIOP fragments allowed per request.</item>
-      <tag><em>iiop_max_in_requests</em></tag>
-      <item>Limits the number of concurrent incoming requests per incoming connection.</item>
-      <tag><em>iiop_max_in_connections</em></tag>
-      <item>Limits the number of concurrent incoming connections.</item>
-      <tag><em>iiop_backlog</em></tag>
-      <item>Defines  the maximum length the queue of pending incoming
-       connections may grow to.</item>
-      <tag><em>iiop_packet_size</em></tag>
-      <item>Defines the maximum size of incoming requests.
-       If this limit is exceeded, the connection is closed.</item>
-      <tag><em>ip_address</em></tag>
-      <item>This option is used if orber only should 
-       listen on a specific ip interface on a multi-interface host or if
-       exported IOR:s should contain multiple components. The value is
-       the IPv4 or IPv6 address as a string or <c>{multiple, IPList}</c>.
-       The latter requires that the object is available via the all IP addresses
-       found in the list.</item>
-      <tag><em>ip_address_local</em></tag>
-      <item>This option defines the default local interface Orber will
-       use when connecting to another ORB via IIOP, i.e., Orber act as the
-       client side ORB. The value is a IPv4 or IPv6 address as a string.
-       It is possible to override <c>ip_address_local</c> by defining
-      <c>iiop_acl</c> or passing the Orber generic <c>interface</c> Context.
-       If this option is not used, the underlying OS will choose which interface to
-       use. For more information, see the
-      <seealso marker="ch_install#interfaces">Interface Configuration</seealso>
-       section.</item>
-      <tag><em>nat_ip_address</em></tag>
-      <item>The value is the ip address as
-       a string (IPv4 or IPv6), <c>{multiple, IPList}</c> or 
-      <c>{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</c>. See also
-      <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item>
-      <tag><em>objectkeys_gc_time</em></tag>
-      <item>This option should be set if objects are started
-       using the option <c>{persistent, true}</c>.
-       The value is <c>integer()</c> seconds.</item>
-      <tag><em>giop_version</em></tag>
-      <item>Defines the default GIOP protocol version.</item>
-      <tag><em>iiop_setup_connection_timeout</em></tag>
-      <item>The value is an integer (seconds) or the atom infinity. 
-       This option is only valid for client-side 
-       connections. If this option is set, attempts to connect to other ORB's
-       will timeout after the given time limit. Note, if the time limit is large
-       the TCP protocol may timeout before the supplied value.</item>
-      <tag><em>iiop_connection_timeout</em></tag>
-      <item>The value is an integer (timeout in seconds between 0 and 1000000) 
-       or the atom infinity. This option is only valid for client object 
-       connections, i.e., will have no effect on server connections. Setting this
-       option will cause client connections to be terminated, if and only if,
-       there are no pending requests. If there are a client still waiting for
-       a reply, Orber will try again after the given seconds have passed. The main
-       purpose for this option is to reduce the number of open connections; it is,
-       for example, not necessary to keep a connection, only used once a day,
-       open at all time.</item>
-      <tag><em>iiop_in_connection_timeout</em></tag>
-      <item>The same as for <c>iiop_connection_timeout</c>. The only difference is
-       that this option only affects incoming connections (i.e. Orber act as
-       server-side ORB).</item>
-      <tag><em>iiop_out_keepalive</em></tag>
-      <item>Enables periodic transmission on a connected socket, when no other 
-       data is being exchanged. If the other end does not respond, the 
-       connection is considered broken and will be terminated. 
-       When enabled the SO_KEEPALIVE socket level option is set.</item>
-      <tag><em>iiop_in_keepalive</em></tag>
-      <item>The same as for <c>iiop_out_keepalive</c>. The only difference is
-       that this option only affects incoming connections.</item>
-      <tag><em>iiop_timeout</em></tag>
-      <item>The value is an integer (timeout in seconds between 0 and 1000000) 
-       or the atom infinity. This option is only valid on the client side.
-       Setting this option, cause all intra-ORB requests to timeout and
-       raise a system exception, e.g. <c>TIMEOUT</c>, if no replies are delivered
-       within the given time limit.</item>
-      <tag><em>interceptors</em></tag>
-      <item>If one set this parameter, e.g.,
-      <c>erl -orber interceptors "{native, ['myInterceptor']}"</c>,
-       Orber will use the supplied interceptor(s) for all inter-ORB 
-       communication. <c>'myInterceptor'</c> is the module name of the
-       interceptor. For more information, see the interceptor chapter
-       in the User's Guide and the Reference Manual.</item>
-      <tag><em>local_interceptors</em></tag>
-      <item>If defined, its value will be
-       used when activating local interceptors via
-      <seealso marker="ch_install#flags">Orber Environment Flags</seealso>.
-       If not defined, but the flag is set, Orber will use the value of
-       the <c>interceptors</c> parameter.</item>
-      <tag><em>orbInitRef</em></tag>
-      <item>Setting this option, e.g., 
-      <c>erl -orber orbInitRef [\"NameService=corbaloc::host.com/NameService\"]</c>, 
-       will alter the location from where <c>corba:resolve_initial_references(Key)</c> 
-       tries to find an object matching the given Key. The keys will also appear when
-       invoking <c>corba:list_initial_services()</c>. This variable overrides
-      <c>orbDefaultInitRef</c></item>
-      <tag><em>orbDefaultInitRef</em></tag>
-      <item>If a matching Key for <c>orbInitRef</c> is not
-       found, and this variable is set, it determines the location from where 
-      <c>orber:resolve_initial_references(Key)</c> tries to find an object 
-       matching the given Key. Usage:
-      <c>erl -orber orbDefaultInitRef \"corbaloc::host.com\"</c>.</item>
-      <tag><em>orber_debug_level</em></tag>
-      <item>The range is 0 to 10.
-       Using level 10 is the most verbose configuration.
-       This option will generate reports, using the <c>error_logger</c>,
-       for abnormal situations. It is not recommended to use this option
-       for delivered systems since some of the reports is not to be considered
-       as errors. The main purpose is to assist during development.</item>
-      <tag><em>flags</em></tag>
-      <item>No flags are activated in the default case.
-       The available configuration settings are described in
-      <seealso marker="ch_install#flags">Orber Environment Flags</seealso>.</item>
-      <tag><em>iiop_acl</em></tag>
-      <item>This option must be activated by setting 
-      <seealso marker="ch_install#flags">Orber Environment Flags</seealso> parameter.
-       The value of this parameter shall be a list of <c>[{Direction, Filter}]</c> 
-       and/or <c>[{Direction, Filter, [Interfaces]}]</c>. The <c>Direction</c>, 
-      <c>tcp_in</c>, <c>ssl_in</c>, <c>tcp_out</c> or <c>ssl_out</c>, determines if
-       the Access Control List (ACL) applies to incoming or outgoing connections
-       and IIOP or IIOP over SSL. The <c>Filter</c> uses a extended format of 
-       Classless Inter Domain Routing (CIDR). For example, <c>"123.123.123.10"</c> limits
-       the connection to that particular host, while <c>"123.123.123.10/17"</c> allows
-       connections to or from any host equal to the 17 most significant bits. Orber
-       also allow the user to specify a certain port or port range, for example,
-      <c>"123.123.123.10/17#4001"</c> and <c>"123.123.123.10/17#4001/5001"</c>
-       respectively. IPv4 or none compressed IPv6 strings are accepted.      <br></br>
-
-       The list of <c>Interfaces</c>, IPv4 or IPv6 strings, may only contain 
-      <em>one</em> address for outgoing connections. For incoming connections,
-       the <c>Interfaces</c> list may contain several IP strings. If set for
-       outgoing connections, and access is granted, Orber will use that local
-       interface when connecting to the server-side ORB. For incoming connections,
-       the client-side ORB is required to use one of the listed interfaces locally.
-       If it fail to do so, access will be denied. The module 
-      <seealso marker="orber_acl">orber_acl</seealso> provides operations for
-       evaluating the access control for filters and addresses. See also the
-      <seealso marker="ch_install#interfaces">Interface Configuration</seealso>
-       and
-      <seealso marker="ch_install#firewall">Firewall Configuration</seealso>
-       chapters.</item>
-      <tag><em>secure</em></tag>
-      <item>Determines the security mode Orber will use, which is either 
-      <c>no</c> if it is an insecure domain or the type of security 
-       mechanism used. Currently, per default, Orber is compliant with
-      <c>CSIv1</c> level 0, which means IIOP via SSL/TLS. 
-       The security chapter later in this manual describes how to get security
-       in Orber and how the options are used.</item>
-      <tag><em>ssl_generation</em></tag>
-      <item>Defines which SSL version, i.e. available API, is installed. The
-      default value, <c>2</c>, refers to SSL-3.1 or later, but earlier than SSL-4.0.
-      If set to <c>3</c> SSL-4.0, or later, must be available. Currently it not possible
-      to use <c>1</c>, it is only reserved for future use.</item>
-      <tag><em>iiop_ssl_port</em></tag>
-      <item>If set, the value must be an
-       integer greater than zero and not equal to <em>iiop_port</em>.</item>
-      <tag><em>iiop_ssl_accept_timeout</em></tag>
-      <item>The value is an integer (timeout in seconds) or the atom infinity and
-       determine how long the SSL handshake may take. This option should
-       be set to avoid if a client never initiate the handshake.</item>
-      <tag><em>iiop_ssl_backlog</em></tag>
-      <item>Defines  the maximum length the queue of pending incoming
-       connections may grow to.</item>
-      <tag><em>iiop_ssl_ip_address_local</em></tag>
-      <item>This option defines the default local interface Orber will
-       use when connecting to another ORB via IIOP SSL, i.e., Orber act as the
-       client side ORB. The value is a IPv4 or IPv6 address as a string.
-       It is possible to override <c>iiop_ssl_ip_address_local</c> by defining
-      <c>iiop_acl</c> or passing the Orber generic <c>interface</c> Context.
-       If this option is not used, the underlying OS will choose which interface to
-       use. For more information, see the
-      <seealso marker="ch_install#interfaces">Interface Configuration</seealso>
-       section.</item>
-      <tag><em>nat_iiop_ssl_port</em></tag>
-      <item>If set, the value must be an integer greater than zero or 
-      <c>{local, DefaultNATPort, [{Port, NATPort}]}</c>. See also
-      <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item>
-      <tag><em>ssl_server_options</em></tag>
-      <item>A list of the SSL options when Orber is the server. 
-        In general it's just to remove the 'ssl_server_' prefix from the old options,
-	i.e. <c>ssl_server_verify</c> will just be <c>verify</c> in this option list.
-        See the <seealso marker="ssl:ssl">SSL application</seealso> for the correct list of possible 
-        options and their values.
-      </item>
-      <tag><em>ssl_client_options</em></tag>
-      <item>A list of the SSL options when Orber is the client. 
-        In general it's just to remove the <c>ssl_client_</c> prefix from the old options,
-	i.e. <c>ssl_client_depth</c> will just be <c>depth</c> in this option list.
-        See the <seealso marker="ssl:ssl">SSL application</seealso> for the correct list of possible 
-        options and their values.
-      </item>
-      <tag><em>iiop_ssl_out_keepalive</em></tag>
-      <item>Enables periodic transmission on a connected socket, when no other 
-       data is being exchanged. If the other end does not respond, the 
-       connection is considered broken and will be terminated. 
-       When enabled the SO_KEEPALIVE socket level option is set. Requires that
-       the installed SSL version support the <em>keepalive</em> option
-       and that the <em>ssl_generation</em> points to this version.</item>
-      <tag><em>iiop_ssl_in_keepalive</em></tag>
-      <item>The same as for <c>iiop_ssl_out_keepalive</c>. The only difference is
-       that this option only affects incoming connections.</item>
-    </taglist>
-    <p>It is possible to invoke operations using the extra timeout parameter:</p>
-    <pre>
-erl> module_interface:function(ObjRef, Timeout, ..Arguments..).
-erl> module_interface:function(ObjRef, [{timeout, Timeout}], ..Arguments..).
-erl> module_interface:function(ObjRef, ..Arguments..).    </pre>
-    <p>The extra Timeout argument will override the configuration parameter 
-      <c>iiop_timeout</c>. It is, however, not possible to use <c>infinity</c>
-      to override the Timeout parameter. The Timeout option is also valid for 
-      objects which resides within the same <term id="Orber domain"><termdef>A domain containing several Erlang nodes, which are communicating  by using the Erlang internal format. An Orber domain looks as one ORB from the environment.</termdef></term>.</p>
-    <p>The <c>iiop_setup_connection_timeout</c>, <c>iiop_timeout</c>,
-      <c>iiop_connection_timeout</c> and <c>iiop_in_connection_timeout</c>
-      variables should be used. The specified values is implementation specific, 
-      i.e., WAN or LAN, but they should range from 
-      <c>iiop_setup_connection_timeout</c> to <c>iiop_connection_timeout</c>.</p>
-    <p>To change these settings in the configuration file, the
-      <c>-config</c> flag must be added to the erl command. See the
-      Reference Manual 
-      <em>config(4)</em> for further information. The values can also
-      be sent separately as
-      options  to the Erlang node when it is started, see the Reference
-      Manual 
-      <em>erl(1)</em> for further information. </p>
-
-    <section>
-      <marker id="flags"></marker>
-      <title>Orber Environment Flags</title>
-      <p>The <c>Environment Flags</c> allows the user to activate debugging
-        facilities or change Orber's behavior. The latter may result in that
-        Orber is no longer compliant with the OMG standard, which may be necessary
-        when communicating with a non-compliant ORB.</p>
-      <table>
-        <row>
-          <cell align="left" valign="middle"><em>Hexadecimal Value</em></cell>
-          <cell align="left" valign="middle"><em>OMG Compliant</em></cell>
-          <cell align="left" valign="middle"><em>Description</em></cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">0001</cell>
-          <cell align="left" valign="middle">no</cell>
-          <cell align="left" valign="middle">Exclude CodeSet Component</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">0002</cell>
-          <cell align="left" valign="middle">yes</cell>
-          <cell align="left" valign="middle">Local Typechecking</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">0004</cell>
-          <cell align="left" valign="middle">yes</cell>
-          <cell align="left" valign="middle">Use Host Name in IOR</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">0008</cell>
-          <cell align="left" valign="middle">yes</cell>
-          <cell align="left" valign="middle">Enable NAT</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">0020</cell>
-          <cell align="left" valign="middle">yes</cell>
-          <cell align="left" valign="middle">Local Interceptors</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">0080</cell>
-          <cell align="left" valign="middle">yes</cell>
-          <cell align="left" valign="middle">Light IFR</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">0100</cell>
-          <cell align="left" valign="middle">yes</cell>
-          <cell align="left" valign="middle">Use IPv6</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">0200</cell>
-          <cell align="left" valign="middle">yes</cell>
-          <cell align="left" valign="middle">EXIT Tolerance</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">0400</cell>
-          <cell align="left" valign="middle">yes</cell>
-          <cell align="left" valign="middle">Enable Incoming ACL</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">0800</cell>
-          <cell align="left" valign="middle">yes</cell>
-          <cell align="left" valign="middle">Enable Outgoing ACL</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">1000</cell>
-          <cell align="left" valign="middle">yes</cell>
-          <cell align="left" valign="middle">Use Current Interface in IOR</cell>
-        </row>
-        <tcaption>Orber Environment Flags</tcaption>
-      </table>
-      <p>Any combination of the flags above may be used and changes the
-        behavior as follows:</p>
-      <list type="bulleted">
-        <item><em>Exclude CodeSet Component</em> - instruct Orber to exclude
-         the CodeSet component in exported IOR:s. When activated, no
-         negotiating regarding character and wide character conversions 
-         between the client and the server will occur. This flag will,
-         most likely, cause problems if your IDL specification contains
-         the data types wchar and/or wstring.</item>
-        <item><em>Local Typechecking</em> -
-         If activated, parameters, replies and raised exceptions
-         will be checked to ensure that the data is correct. If an error
-         occurs, the <c>error_logger</c> is used to generate reports.
-         One <em>MAY NOT</em> use this option for delivered systems due
-         to the extra overhead. Since this option activates typechecking
-         for all objects generated on the target node, it is also possible
-         to use the option <c>{local_typecheck, boolean()}</c>, when
-         invoking <c>oe_create/2</c>, <c>oe_create_link/2</c>,
-        <c>corba:create/4</c> or <c>corba:create_link/4</c>, to override
-         the configuration parameter.</item>
-        <item><em>Use Host Name in IOR</em> - normally Orber inserts the IP-number
-         in IOR:s when they are exported. In some cases, this will cause
-         the clients to open two connections instead of one.</item>
-        <item><em>Enable NAT</em> - if this flag is set, it is possible to use
-         the NAT (Network Address Translation) configuration parameters
-         (<c>nat_iiop_port</c>, <c>nat_iiop_ssl_port</c> and 
-        <c>nat_ip_address</c>).</item>
-        <item><em>Local Interceptors</em> - use interceptors for local
-         invocations.</item>
-        <item><em>Light IFR</em> - if the IFR is not explicitly used and this 
-         flag is set, Orber will use a minimal IFR to reduce memory usage
-         and installation time.</item>
-        <item><em>Use IPv6</em> - when this option is activated, Orber will use
-        <c>IPv6</c> for inter-ORB communication.</item>
-        <item><em>EXIT Tolerance</em> - servers will survive even though the
-         call-back module caused an EXIT.</item>
-        <item><em>Enable Incoming ACL</em> - activates access control for incoming
-         connections.</item>
-        <item><em>Enable Outgoing ACL</em> - activates access control for outgoing
-         connections.</item>
-        <item><em>Use Current Interface in IOR</em> - when set, Orber will add
-         the interface the request came via to exported local IOR:s.</item>
-      </list>
-      <p>Invoking the operation
-        <seealso marker="orber">orber:info/1/2</seealso> will display the currently
-        set flags in a readable way.</p>
-    </section>
-  </section>
-
-  <section>
-    <title>Firewall Configuration</title>
-    <marker id="firewall"></marker>
-    <p>Firewalls are used to protect objects from clients in other networks or 
-      sub-networks, but also to restrict which hosts internal objects may connect to
-      (i.e. <c>inbound protection</c> and <c>outbound protection</c>). A firewall
-      can limit access based on:</p>
-    <list type="bulleted">
-      <item><em>Transport Level</em> - performs access control decisions based on
-       address information in TCP headers.</item>
-      <item><em>Application Level</em> - understands GIOP messages and the specific
-       transport level inter-ORB Protocol supported e.g. IIOP.</item>
-    </list>
-    <p>This section describes how to configure a <c>Transport Level</c> firewall. It
-      must have prior knowledge of the source to destination mappings, and
-      conceptually has a configuration table containing tuples of the form: 
-      <c>({inhost:inport}, {outhost:outport})</c>. If there are no port restrictions
-      it is rather easy to configure the firewall. Otherwise, we must consider the
-      following alternatives:</p>
-    <list type="bulleted">
-      <item><em>Incoming Requests</em> - Orber only uses the port-numbers specified 
-       by the configuration parameters <em>iiop_port</em> and 
-      <em>iiop_ssl_port</em>. Other ORB's may use several ports but it should
-       be possible to change this behavior. Consult the other ORBs 
-       documentation.</item>
-      <item><em>Outgoing Requests</em> - Most ORB's, Orber included,
-       ask the OS to supply a vacant local port when connecting to the
-       server-side ORB. It is possible to change this behavior when using
-       Orber (i.e. set the configuration parameter <em>iiop_out_ports</em>).</item>
-    </list>
-    <warning>
-      <p>Using the option <c>iiop_out_ports</c> may result in that Orber runs out of
-        valid ports numbers. For example, other applications may steal some of the
-        ports or the number of concurrent outgoing connections to other ORBs may be 
-        higher than expected. To reduce, but not eliminate, the risk you should use 
-        <c>iiop_connection_timeout</c>.</p>
-    </warning>
-    <p>Firewall configuration example:</p>
-    <pre>
-# "Plain" IIOP
-To: Orber-IPNo:(iiop_port)     From: ORB-IPNo:X
-To: ORB-IPNo:Z                 From: Orber-IPNo:(iiop_out_ports | Any Port)
-
-# IIOP via SSL
-To: Orber-IPNo:(iiop_port)     From: ORB-IPNo:X
-To: Orber-IPNo:(iiop_ssl_port) From: ORB-IPNo:Y
-To: ORB-IPNo:Z                 From: Orber-IPNo:(iiop_out_ports | Any Port)
-    </pre>
-    <p>If the communication take place via a
-      <seealso marker="ch_install#firewall_nat">TCP Firewall with NAT</seealso>
-      (Network Address Translation), we must activate this behavior and define
-      the external address and/or ports.</p>
-    <marker id="firewall_nat"></marker>
-    <image file="firewall_nat.gif">
-      <icaption>
-TCP Firewall With NAT</icaption>
-    </image>
-    <p>Using NAT makes it possible to use different host data for different network
-      domains. This way we can share Internet Protocol address resources or
-      obscure resources. To enable this feature the 
-      <seealso marker="ch_install#flags">Enable NAT</seealso> flag must be set and
-      <c>nat_iiop_port</c>, <c>nat_iiop_ssl_port</c> and <c>nat_ip_address</c>
-      configured, which maps to <c>iiop_port</c>, <c>iiop_ssl_port</c> and 
-      <c>ip_address</c> respectively. Hence, the firewall must be configured to
-      translate the external to the internal representation correctly. If these NAT parameters 
-      are assigned a single port number or IP address, only those will be used when
-      an IOR is exported to another ORB. When <c>ip_address</c> is set to 
-      <c>{multiple, [IPAddress]}</c>, <c>nat_ip_address</c> should be configured in the same 
-      way, so that each NAT IP address can be translated to a valid address by the firewall.
-      If objects are supposed to be accessible via different interfaces and port, see also
-      <seealso marker="ch_install#interfaces">Interface Configuration</seealso>, 
-      the options <c>{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</c> and/or
-      <c>{local, DefaultNATPort, [{Port, NATPort}]}</c> shall be used. The default NAT IP address
-      and port, should be translated to the value of <c>ip_address_local</c> and the default 
-      listen port by the firewall. If the IP address and/or port is not found in the list,
-      the default values will be inserted in the IOR. The firewall must be able to translate
-      these correctly.</p>
-    <p>If it is necessary to limit the access to an ORB within a secure network,
-      but other applications running on the same host may not be blocked out,
-      one can use a <em>Application Level</em> firewall or Orber Access Control 
-      List (ACL). The latter makes it possible for the user to define which hosts
-      may communicate, either as server or client, with Orber. This is achieved by
-      defining the configuration parameter
-      <seealso marker="ch_install#config">iiop_acl</seealso>. The Classless Inter
-      Domain Routing (CIDR) <c>Filter</c> determines which peer interfaces and 
-      ports the other ORB may use.</p>
-    <table>
-      <row>
-        <cell align="left" valign="middle"><em>Filter</em></cell>
-        <cell align="left" valign="middle"><em>Peer Interface(s)</em></cell>
-        <cell align="left" valign="middle"><em>Peer Port(s)</em></cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">"10.1.1.1"</cell>
-        <cell align="left" valign="middle">10.1.1.1</cell>
-        <cell align="left" valign="middle">any</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">"10.1.1.1/8"</cell>
-        <cell align="left" valign="middle">10.0.0.0-10.255.255.255</cell>
-        <cell align="left" valign="middle">any</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">"10.1.1.1/8#4001"</cell>
-        <cell align="left" valign="middle">10.0.0.0-10.255.255.255</cell>
-        <cell align="left" valign="middle">4001</cell>
-      </row>
-      <row>
-        <cell align="left" valign="middle">"10.1.1.1/8#4001/5001"</cell>
-        <cell align="left" valign="middle">10.0.0.0-10.255.255.255</cell>
-        <cell align="left" valign="middle">4001-5001</cell>
-      </row>
-      <tcaption>Orber ACL Filters</tcaption>
-    </table>
-    <p>Orber ACL, also allows the user to define which local interface(s) may be used,
-      but will not detect <c>spoofing</c>. The operation
-      <seealso marker="orber_acl">orber_acl:match/2/3</seealso> makes it easy to
-      verify whether access would be granted or not. For example, if Orber would
-      be started with the ACL <c>[{tcp_out, "10.1.1.1/8#4001/5001"}]</c>, then 
-      <c>orber_acl:match/2</c> would behave as follows:</p>
-    <code type="erl">
-erl> orber_acl:match({11,1,1,1}, tcp_out).
-false
-
-erl> orber_acl:match({10,1,1,1}, tcp_out).
-true
-
-erl> orber_acl:match({11,1,1,1}, tcp_out, true).
-{false,[],0}
-
-erl> orber_acl:match({10,1,1,1}, tcp_out, true).
-{true,[],{4001,5001}}
-    </code>
-    <p>Only if the returned boolean is true the extra return values makes a 
-      difference. In the example above, <c>{true,[],{4001,5001}}</c> means that
-      Orber may connect to <c>"10.1.1.1"</c>, using any local interface,
-      if the server-side ORB listens for incoming connect requests on a port
-      within the range 4001-5001. Note, invoking the <c>orber_acl:match/2/3</c>
-      operation, will not result in a connect attempt by Orber. The reason for 
-      this, is that this function may be used on a live node as well as in test
-      environment. Hence, if a local interface is currently not available or no 
-      server-side ORB available via the given host/port(s), will not be detected
-      by Orber.</p>
-  </section>
-
-  <section>
-    <title>Interface Configuration</title>
-    <marker id="interfaces"></marker>
-    <p>In many cases it is sufficient to simply configure the underlying OS which
-      local interfaces shall be used for all applications. But, in some cases
-      it is required, due to, for example, the firewall configuration, that different
-      local interfaces are used for different applications. Some times, it is even
-      necessary to use a specific interface for a single CORBA object. This section
-      describe how one can alter this in different ways.</p>
-    <p>The default behavior is that Orber lets the OS configuration decide which interface
-      will be added in IOR:s exported to another ORB and the local interface used
-      when connecting to another ORB (Orber act as client side ORB). The latter can be
-      overridden by setting the configuration parameters <c>iiop_ssl_ip_address_local</c>
-      and/or <c>ip_address_local</c>, which will affect IIOP via SSL and IIOP 
-      respectively. These parameters can be overridden by using the Orber generic 
-      <c>interface</c> Context or defining an ACL (Access Control List). The latter
-      always takes precedence if a local interface is included (e.g. 
-      <c>[{tcp_out, "10.0.0.0/8", ["10.0.0.1"]}]</c>). If the interface is excluded
-      (e.g. <c>[{tcp_out, "10.0.0.0/8"}]</c>), the interface chosen will, in the following
-      order, be determined by
-      <c>#'IOP_ServiceContext'{}</c>, <c>ip_address_local/iiop_ssl_ip_address_local</c> or
-      the configuration of the underlying system.</p>
-    <p>Adding the interface context, for generated stubs/skeletons, is done in the 
-      following way:</p>
-    <code type="erl">
-Ctx = #'IOP_ServiceContext'{context_id = ?ORBER_GENERIC_CTX_ID, 
-                            context_data = {interface, "10.0.0.1"}},
-'CosNaming_NamingContext':resolve(NS, [{context, [Ctx]}], Name),
-    </code>
-    <p>It is also possible to add the context to 
-      <c>corba:string_to_object/2, corba:resolve_initial_references/2, corba:resolve_initial_references_remote/3,  corba:list_initial_services_remote/2, corba_object:not_existent/2,  corba_object:non_existent/2</c> and <c>corba_object:is_a/3</c>. 
-      The operations exported by <c>corba_object</c> are affected
-      if the supplied IOR is external. The function <c>corba:string_to_object/2</c>
-      might require the interface context if a <c>corbaloc</c> or a <c>corbaloc</c>
-      string is passed (See the
-      <seealso marker="ch_naming_service#interop_ns">INS</seealso> chapter),
-      while <c>corba:resolve_initial_references_remote/3</c> and
-      <c>corba:list_initial_services_remote/2</c> always connect to another ORB and
-      it might be necessary to add the context.
-      The remaining <c>corba</c> operations are affected if calls are re-directed
-      by setting the <c>orbInitRef</c> and/or <c>orbDefaultInitRef</c> configuration
-      parameters. For more information, see the Reference Manual for each module.</p>
-    <p>Configuring which interface(s) that shall be used when exporting an IOR to
-      another ORB, is determined by <c>nat_ip_address</c>, setting the flag 
-      <seealso marker="ch_install#flags">16#1000</seealso>
-      and <c>ip_address</c>, in that order. Orber listens for incoming connections
-      either via all interfaces or the interface defined by <c>ip_address</c>. It is
-      also possible to add and remove extra listen interfaces by using
-      <c>orber:add_listen_interface/2/3</c> and <c>orber:remove_listen_interface/1</c>.
-      In this case one should set the 16#1000 flag and, if necessary, set the
-      configuration parameters
-      <c>{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</c> and/or
-      <c>{local, DefaultNATPort, [{Port, NATPort}]}</c>.</p>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_interceptors.xml b/lib/orber/doc/src/ch_interceptors.xml
deleted file mode 100644
index 4a9f8e69ca..0000000000
--- a/lib/orber/doc/src/ch_interceptors.xml
+++ /dev/null
@@ -1,278 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-   <header>
-    <copyright>
-      <year>2001</year><year>2017</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>Orber Interceptors</title>
-    <prepared>Nick</prepared>
-    <docno></docno>
-    <date>2001-08-16</date>
-    <rev></rev>
-    <file>ch_interceptors.xml</file>
-  </header>
-
-  <section>
-    <title>Using Interceptors</title>
-    <p>For Inter-ORB communication, e.g., via <c>IIOP</c>, it is possible
-      to intercept requests and replies. To be able to use <c>Interceptors</c>
-      Orber the configuration parameter <c>interceptors</c> must be defined.</p>
-
-    <section>
-      <title>Configure Orber to Use Interceptors</title>
-      <p>The configuration parameter <c>interceptors</c> must be defined, e.g.,
-        as command line option:</p>
-      <code type="none">
-erl -orber interceptors "{native, ['myInterceptor']}"
-      </code>
-      <p>It is possible to use more than one interceptor; simply add them to the
-        list and they will be invoked in the same order as they appear in the list.</p>
-      <p>One can also active and deactivate an interceptor during
-        run-time, but this will only affect currently existing connections. 
-        For more information, consult Orber's Reference Manual regarding the
-        operations <c>orber:activate_audit_trail/0/1</c> and
-        <c>orber:activate_audit_trail/0/1.</c></p>
-    </section>
-
-    <section>
-      <title>Creating Interceptors</title>
-      <p>Each supplied interceptor <em>must</em> export the following functions:</p>
-      <list type="bulleted">
-        <item><em>new_out_connection/3/5</em> - one of these operations is called when
-         a client application calls an object residing on remote ORB.
-         If an interceptor exports both versions, arity 3 and 5, which
-         operation that will be invoked is Orber internal.</item>
-        <item><em>new_in_connection/3/5</em> - one of these operations is invoked
-         when a client side ORB tries to set up a connection to the target ORB.
-         If an interceptor exports both versions, arity 3 and 5, which
-         operation that will be invoked is Orber internal.</item>
-        <item><em>out_request/6</em> - supplies all request data on the client side
-         ORB.</item>
-        <item><em>out_request_encoded/6</em> - similar to <c>out_request</c>
-         but the request body is encode.</item>
-        <item><em>in_request_encoded/6</em> - after a new request arrives at the
-         target ORB the request data is passed to the interceptor in
-         encoded format.</item>
-        <item><em>in_request/6</em> - prior to invoking the operation on the
-         target object, the interceptor <c>in_request</c> is called.</item>
-        <item><em>out_reply/6</em> - after the target object replied the
-        <c>out_reply</c> operation is called with the result of the object
-         invocation.</item>
-        <item><em>out_reply_encoded/6</em> - before sending a reply back to the
-         client side ORB this operation is called with the result in 
-         encoded format.</item>
-        <item><em>in_reply_encoded/6</em> - after the client side ORB receives
-         a reply this function is called with the reply in encoded 
-         format.</item>
-        <item><em>in_reply/6</em> - before delivering the reply to the client
-         this operation is invoked.</item>
-        <item><em>closed_in_connection/1</em> - when a connection is terminated
-         on the client side this function is called.</item>
-        <item><em>closed_out_connection/1</em> - if an outgoing connection is
-         terminated this operation will be invoked.</item>
-      </list>
-      <p>The operations <c>new_out_connection</c>, <c>new_in_connection</c>, 
-        <c>closed_in_connection</c> and <c>closed_out_connection</c> operations
-        are only invoked <em>once</em> per connection. The remaining operations
-        are called, as shown below, for every Request/Reply to/from remote
-        CORBA Objects.</p>
-      <marker id="interceptor_operations"></marker>
-      <image file="interceptor_operations.gif">
-        <icaption>
-The Invocation Order of Interceptor Functions.</icaption>
-      </image>
-    </section>
-  </section>
-
-  <section>
-    <title>Interceptor Example</title>
-    <p>Assume we want to create a simple access service which purpose is to:</p>
-    <list type="bulleted">
-      <item>Only allow incoming request from ORB's residing on a certain set of
-       nodes.</item>
-      <item>Restrict the objects any client may invoke operations on.</item>
-      <item>Only allow outgoing requests to call a limited set of external
-       ORB's.</item>
-      <item>Add a checksum to each binary request/reply body.</item>
-    </list>
-    <p>To restricts the access we use a <c>protected</c> and <c>named</c> ets-table
-      holding all information. How the ets-table is initiated and maintained
-      is implementation specific, but it contain 
-      <c>{Node, ObjectTable, ChecksumModule}</c> where <c>Node</c> is used as 
-      ets-key, <c>ObjectTable</c> is a reference to another ets-table in which
-      we store which objects the clients are allowed to invoke operations on
-      and <c>ChecksumModule</c> determines which module we should use to handle
-      the checksums. </p>
-    <code type="erl">
-new_in_connection(Arg, Host, Port) ->
-    %% Since we only use one interceptor we do not care about the
-    %% input Arg since it is set do undefined by Orber.
-    case ets:lookup(in_access_table, Host) of
-         [] ->
-            %% We may want to log the Host/Port to see if someone tried
-            %% to hack in to our system.
-            exit("Access not granted");
-         [{Host, ObjTable, ChecksumModule}] ->
-            {ObjTable, ChecksumModule}
-    end.
-    </code>
-    <p>The returned tuple, i.e., {ObjTable, ChecksumModule}, will be passed
-      as the first argument whenever invoking one of the interceptor functions.
-      Unless the connection attempt did not fail we are now ready for receiving
-      requests from the client side ORB.</p>
-    <p>When a new request comes in the first interceptor function to be invoked is
-      <c>in_request_encoded</c>. We will remove the checksum from the coded
-      request body in the following way:</p>
-    <code type="erl">
-in_request_encoded({ObjTable, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) ->
-    NewBin = ChecksumModule:remove_checksum(Bin),
-    {NewBin, Extra}.
-    </code>
-    <p>If the checksum check fails the <c>ChecksumModule</c> should invoke exit/1.
-      But if the check succeeded we are now ready to check if the client-ORB 
-      objects are allowed to invoke operations on the target object. Please note,
-      it is possible to run both checks in <c>in_request_encoded</c>. Please
-      note, the checksum calculation must be relatively fast to ensure a
-      good throughput.</p>
-    <p>If we want to we can restrict any clients to only use a subset of operations
-      exported by a server:</p>
-    <code type="erl">
-in_request({ObjTable, ChecksumModule}, ObjKey, Ctx, Op, Params, Extra) ->
-    case ets:lookup(ObjTable, {ObjKey, Op}) of
-         [] ->
-            exit("Client tried to invoke illegal operation");
-         [SomeData] ->
-            {Params, Extra}
-    end.
-    </code>
-    <p>At this point Orber are now ready to invoke the operation on the target 
-      object. Since we do not care about what the reply is the <c>out_reply</c>
-      function do nothing, i.e.:</p>
-    <code type="erl">
-out_reply(_, _, _, _, Reply, Extra) ->
-    {Reply, Extra}.
-    </code>
-    <p>If the client side ORB expects a checksum to be added to the reply we
-      add it by using:</p>
-    <code type="erl">
-out_reply_encoded({ObjTable, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) ->
-    NewBin = ChecksumModule:add_checksum(Bin),
-    {NewBin, Extra}.
-    </code>
-    <warning>
-      <p>If we manipulate the binary as above the behavior <em>must</em>
-        be <c>Bin == remove_checksum(add_checksum(Bin))</c>.</p>
-    </warning>
-    <p>For outgoing requests the principle is the same. Hence, it is not further
-      described here. The complete interceptor module would look like:</p>
-    <code type="erl">
--module(myInterceptor).
-
-%% Interceptor functions.
--export([new_out_connection/3,
-     new_in_connection/3,
-     closed_in_connection/1,
-     closed_out_connection/1,
-     in_request_encoded/6,
-     in_reply_encoded/6,
-     out_reply_encoded/6,
-     out_request_encoded/6,
-     in_request/6,
-     in_reply/6,
-     out_reply/6,
-     out_request/6]).
-
-new_in_connection(Arg, Host, Port) ->
-    %% Since we only use one interceptor we do not care about the
-    %% input Arg since it is set do undefined by Orber.
-    case ets:lookup(in_access_table, Host) of
-         [] ->
-            %% We may want to log the Host/Port to see if someone tried
-            %% to hack in to our system.
-            exit("Access not granted");
-         [{Host, ObjTable, ChecksumModule}] ->
-            {ObjTable, ChecksumModule}
-    end.
-
-new_out_connection(Arg, Host, Port) ->
-    case ets:lookup(out_access_table, Host) of
-         [] ->
-            exit("Access not granted");
-         [{Host, ObjTable, ChecksumModule}] ->
-            {ObjTable, ChecksumModule}
-    end.
-
-in_request_encoded({_, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) ->
-    NewBin = ChecksumModule:remove_checksum(Bin),
-    {NewBin, Extra}.
-
-in_request({ObjTable, _}, ObjKey, Ctx, Op, Params, Extra) ->
-    case ets:lookup(ObjTable, {ObjKey, Op}) of
-         [] ->
-            exit("Client tried to invoke illegal operation");
-         [SomeData] ->
-            {Params, Extra}
-    end.
-
-out_reply(_, _, _, _, Reply, Extra) ->
-    {Reply, Extra}.
-
-out_reply_encoded({_, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) ->
-    NewBin = ChecksumModule:add_checksum(Bin),
-    {NewBin, Extra}.
-
-out_request({ObjTable, _}, ObjKey, Ctx, Op, Params, Extra) ->
-    case ets:lookup(ObjTable, {ObjKey, Op}) of
-         [] ->
-            exit("Client tried to invoke illegal operation");
-         [SomeData] ->
-            {Params, Extra}
-    end.
-
-out_request_encoded({_, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) ->
-    NewBin = ChecksumModule:add_checksum(Bin),
-    {NewBin, Extra}.
-
-in_reply_encoded({_, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) ->
-    NewBin = ChecksumModule:remove_checksum(Bin),
-    {NewBin, Extra}.
-
-in_reply(_, _, _, _, Reply, Extra) ->
-    {Reply, Extra}.
-
-closed_in_connection(Arg) ->
-    %% Nothing to clean up.
-    Arg.
-
-closed_out_connection(Arg) ->
-    %% Nothing to clean up.
-    Arg.
-    </code>
-    <note>
-      <p>One can also use interceptors for debugging purposes, e.g.,
-        print which objects and operations are invoked with which arguments
-        and the outcome of the operation. In conjunction with the configuration
-        parameter <c>orber_debug_level</c> it is rather easy to find out what
-        went wrong or just to log the traffic.  </p>
-    </note>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_introduction.xml b/lib/orber/doc/src/ch_introduction.xml
deleted file mode 100644
index f04fedd0a7..0000000000
--- a/lib/orber/doc/src/ch_introduction.xml
+++ /dev/null
@@ -1,145 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>1999</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>Introduction to Orber</title>
-    <prepared>Megan Lynch</prepared>
-    <docno></docno>
-    <date>1998-09-21</date>
-    <rev></rev>
-    <file>ch_introduction.xml</file>
-  </header>
-
-  <section>
-    <title>Overview</title>
-    <p>The Orber application is a CORBA compliant Object Request Brokers
-      (ORB), which provides CORBA functionality in an Erlang
-      environment. Essentially, the ORB channels communication or
-      transactions between nodes in a
-      heterogeneous environment.
-      </p>
-    <p><term id="CORBA"><termdef>Common Object Request Broker Architecture is a common communication standard developed by the OMG (Object Management Group)</termdef></term>(Common Object Request Broker
-      Architecture) provides an interface definition language  allowing
-      efficient system integration and also supplies standard
-      specifications for some services.
-      </p>
-    <p>The Orber application contains the following parts:</p>
-    <list type="bulleted">
-      <item>
-        <p>ORB kernel and IIOP support</p>
-      </item>
-      <item>
-        <p>Interface Repository</p>
-      </item>
-      <item>
-        <p>Interface Definition Language Mapping for Erlang</p>
-      </item>
-      <item>
-        <p>CosNaming Service</p>
-      </item>
-    </list>
-
-    <section>
-      <title>Benefits</title>
-      <p>Orber provides CORBA functionality in an Erlang environment that enables:
-        </p>
-      <list type="bulleted">
-        <item>
-          <p><em>Platform interoperability and transparency</em></p>
-          <p>Orber enables communication between
-            OTP applications or Erlang environment applications and
-            other platforms; for example,  Windows NT, Solaris
-            etc, allowing platform  transparency. This is especially helpful in situations where there
-            are many users with  different platforms.  For example,
-            booking airline tickets would require the airline database
-            and hundreds of travel agents (who may not have the same
-            platform) to book seats on flights. </p>
-        </item>
-        <item>
-          <p><em>Application level interoperability and transparency</em></p>
-          <p>As Orber is a CORBA compliant application, its purpose is
-            to provide interoperability and transparency on the application
-            level. 
-            Orber simplifies the distributed system software  by defining the
-            environment as  objects, which in effect, views
-            everything as identical regardless of programming
-            languages.            <br></br>
- Previously, time-consuming programming was
-            required to facilitate communication between different languages.
-            However, with CORBA compliant Orber the Application
-            Programmer is relieved of this task. This makes 
-            communication on an application level relatively transparent to the user.</p>
-        </item>
-      </list>
-    </section>
-
-    <section>
-      <title>Purpose and Dependencies</title>
-      <p>The system architecture and OTP dependencies of Orber are illustrated in figure 1 below:</p>
-      <marker id="dependent"></marker>
-      <image file="dependent.gif">
-        <icaption>
-Figure 1: Orber Dependencies and Structure.</icaption>
-      </image>
-      <p>Orber  is dependent on  Mnesia (see the Mnesia
-        documentation) - an Erlang database management application
-        used to store object information.</p>
-      <note>
-        <p>Although Orber does not have a  run-time
-          application dependency to IC (an <term id="IDL"><termdef>Interface Definition Language - IDL is the OMG specified interface definition language, used to define the CORBA object interfaces.</termdef></term>compiler for
-          Erlang), it is necessary when building
-          services and applications.  See the IC documentation for
-          further details.</p>
-      </note>
-      <marker id="orbs"></marker>
-      <image file="orbs.gif">
-        <icaption>
-Figure 2: ORB interface between Java and Erlang Environment Nodes.</icaption>
-      </image>
-      <p>This simplified illustration in figure 2 demonstrates how Orber can facilitate communication in a heterogeneous environment. The Erlang Nodes running 
-        OTP and the other Node running applications written in Java  can
-        communicate via an <term id="ORB"><termdef>Object Request Broker - ORB open software bus architecture specified by the OMG which allows object components to communicate in a heterogeneous environment.</termdef></term>(Object Request Broker). Using
-        Orber means that CORBA functions can be used to achieve this
-        communication.
-        </p>
-      <p>For example, if one of the above nodes requests an object, it does not
-        need to know if that object is located on the same, or 
-        different, Erlang or Java nodes. The ORB will channel the
-        information creating platform and application transparency for
-        the user.
-        </p>
-    </section>
-
-    <section>
-      <title>Prerequisites</title>
-      <p>To fully understand the concepts presented in the
-        documentation, it is recommended that the user is familiar
-        with distributed programming and CORBA (Common Object Request
-        Broker Architecture).  
-        </p>
-      <p>Recommended reading includes <em>Open Telecom Platform Documentation Set</em> and <em>Concurrent Programming in Erlang</em>.
-        </p>
-    </section>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_naming_service.xml b/lib/orber/doc/src/ch_naming_service.xml
deleted file mode 100644
index 991402ae86..0000000000
--- a/lib/orber/doc/src/ch_naming_service.xml
+++ /dev/null
@@ -1,465 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>1997</year><year>2017</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>CosNaming Service</title>
-    <prepared></prepared>
-    <docno></docno>
-    <date>1998-10-10</date>
-    <rev></rev>
-    <file>ch_naming_service.xml</file>
-  </header>
-
-  <section>
-    <title>Overview of the CosNaming Service</title>
-    <p>The CosNaming Service is a service developed to help users and
-      programmers identify objects by human readable names rather than by a
-      reference.  By  binding a name to a naming context (another object), a
-      contextual reference is formed. This is helpful when navigating in the
-      object space. In addition, identifying objects by name allows you to evolve
-      and/or relocate objects without client code modification.</p>
-    <p>The CosNaming service has some concepts that are important:</p>
-    <list type="bulleted">
-      <item>
-        <p><em>name binding</em> - a name to object association.</p>
-      </item>
-      <item>
-        <p><em>naming context</em> - is an object that contains a set of
-          name bindings in which each name is unique. Different names can be
-          bound to the same object.  
-          </p>
-      </item>
-      <item>
-        <p><em>to bind a name</em> - is to create a name binding in a given
-          context.</p>
-      </item>
-      <item>
-        <p><em>to resolve a name</em> - is to determine the object associated
-          with the name in a given context.</p>
-      </item>
-    </list>
-    <p>A name is always resolved in a context, there no absolute names exist.
-      Because a context is like any other object, it can also be bound to
-      a name
-      in a naming context. 
-      This will result in a naming graph (a directed graph with notes and 
-      labeled edges). The graph allows more complex names to refer to an
-      object. Given a context, you can use a sequence to reference an object.
-      This sequence is henceforth referred to as <em>name</em> and the
-      individual
-      elements in the sequence as <em>name components</em>. All but the 
-      last name component are bound to naming contexts.
-      </p>
-    <p>The diagram in figure 1 illustrates how the Naming Service provides a
-      contextual relationship between objects, NamingContexts and
-      NameBindings to create an object locality, as the
-      object itself, has no name.
-      </p>
-    <marker id="name"></marker>
-    <image file="name.gif">
-      <icaption>
-Figure 1: Contextual object relationships using the Naming Service.</icaption>
-    </image>
-    <p>The naming contexts provide a directory of contextual
-      reference and naming for objects (an object can appear to 
-      have more than one name).
-      </p>
-    <p>In figure 1 the object to the right can either be
-      called <c>alpha</c> from one context or <c>gamma</c> from another.  
-      </p>
-    <p>The Naming Service has an initial naming context, which is shown 
-      in the diagram as the top-most object in the naming graph.
-      It has two names <c>beta</c> and <c>epsilon</c>, which are bound to other
-      naming contexts. The initial naming context is a well known location 
-      used to share a common name space between multiple programs.
-      You can traverse the naming graph until you reach a name, which is
-      bound to an object, which is not a naming context.
-      </p>
-    <p>We recommend reading <em>chapter 12, CORBA Fundamentals and Programming</em>, for detailed information regarding the 
-      Naming Service. </p>
-  </section>
-
-  <section>
-    <title>The Basic Use-cases of the Naming Service</title>
-    <p>The basic use-cases of the Naming Service are:
-      </p>
-    <list type="bulleted">
-      <item>Fetch initial reference to the naming service.</item>
-      <item>Creating a naming context.</item>
-      <item>Binding and unbinding names to objects.</item>
-      <item>Resolving a name to an object.</item>
-      <item>Listing the bindings of a naming context.</item>
-      <item>Destroying a naming context.</item>
-    </list>
-
-    <section>
-      <title>Fetch Initial Reference to the Naming Service</title>
-      <p>In order to use the naming service you have to fetch an 
-        initial reference to it. This is done with:</p>
-      <code type="erl">
-NS = corba:resolve_initial_references("NameService").
-      </code>
-      <note>
-        <p>NS in the other use-cases refers to this initial reference.</p>
-      </note>
-    </section>
-
-    <section>
-      <title>Creating a Naming Context</title>
-      <p>There are two functions for creating a naming context.
-        The first function, which only creates a naming context object is:</p>
-      <code type="erl">
-NC = 'CosNaming_NamingContext':new_context(NS).
-      </code>
-      <p>The other function creates a naming context and binds it to a name in 
-        an already existing naming context (the initial context in this 
-        example):
-        </p>
-      <code type="erl">
-NC = 'CosNaming_NamingContext':bind_new_context(NS, lname:new(["new"])).
-      </code>
-    </section>
-
-    <section>
-      <title>Binding and Unbinding Names to Objects</title>
-      <p>The following steps illustrate how to bind/unbind an object reference 
-        to/from a name. For the example below, assume that the NamingContexts 
-        in the path are already bound to the name <c>/workgroup/services</c>, 
-        and that reference to the services context are in the variable 
-        <c>Sc</c>.</p>
-      <list type="ordered">
-        <item>
-          <p>Use the naming library functions to create a name</p>
-          <code type="erl">
-Name = lname:new(["object"]).
-          </code>
-        </item>
-        <item>
-          <p>Use CosNaming::NamingContext::bind() to bind a name to an object</p>
-          <code type="erl">
-'CosNaming_NamingContext':bind(Sc, Name, Object).
-          </code>
-        </item>
-        <item>
-          <p>Use CosNaming::NamingContext::unbind() to remove the NameBinding from an object</p>
-          <code type="erl">
-'CosNaming_NamingContext':unbind(Sc, Name).
-          </code>
-        </item>
-      </list>
-      <note>
-        <p>Objects can have more than one name, to indicate different paths to 
-          the same object.</p>
-      </note>
-    </section>
-
-    <section>
-      <title>Resolving a Name to an Object</title>
-      <p>The following steps show how to  retrieve the object reference to the service context 
-        above (/workgroup/services).    </p>
-      <list type="ordered">
-        <item>
-          <p>Use the naming library functions to create a name path:</p>
-          <code type="erl">
-Name = lname:new(["workgroup", "services"]).
-          </code>
-        </item>
-        <item>
-          <p>Use CosNaming::NamingContext::resolve() to to resolve the name to an object</p>
-          <code type="erl">
-Sc = 'CosNaming_NamingContext':resolve(NS, Name).
-          </code>
-        </item>
-      </list>
-      <p>An alternative is to use:</p>
-      <code type="erl">
-Sc = corba:string_to_object("corbaname:rir:/NameService#workgroup/services/").
-      </code>
-      <p>The <c>corbaname</c> schema is described further in the Interoperable
-        Naming Service section.</p>
-    </section>
-
-    <section>
-      <title>Listing the Bindings in a NamingContext</title>
-      <list type="ordered">
-        <item>
-          <p>Use CosNaming::NamingContext::list() to list all the bindings in a context</p>
-          <p>The following code retrieves and lists up to 10 bindings from a context.</p>
-          <code type="erl">
-{BList, BIterator} = 'CosNaming_NamingContext':list(Sc, 10).
-
-lists:foreach(fun({{Id, Kind},BindingType}) -> case BindingType of 
-    nobject ->
-        io:format("id: %s, kind: %s, type: object~n", [Id, Kind]);
-    _ ->
-        io:format("id: %s, kind: %s, type: ncontext~n", [Id, Kind])
-    end end,
-    Blist).
-          </code>
-        </item>
-      </list>
-      <note>
-        <p>Normally a <term id="BindingIterator"><termdef>The binding iterator (Like a book mark) indicates which objects have been read from the list.</termdef></term>is helpful in situations where you have a large number of objects 
-          in a list, as the programmer then can traverse it more easily.
-          In Erlang it is not needed, because lists are easily handled in the 
-          language itself.</p>
-      </note>
-      <warning>
-        <p>Remember that the BindingIterator (BIterator in the example) is an object and therefore
-          <em>must be removed</em> otherwise dangling processes will occur.
-          Use <c>CosNaming::BindingIterator::destroy()</c> to remove it.</p>
-      </warning>
-      <code type="erl">
-'CosNaming_NamingContext':destroy(BIterator).
-      </code>
-    </section>
-
-    <section>
-      <title>Destroying a Naming Context</title>
-      <p>The naming contexts are persistent and must be explicitly removed.
-        (they are also removed if all Orber nodes in the domain are stopped).</p>
-      <list type="ordered">
-        <item>
-          <p>Use CosNaming::NamingContext::destroy() to remove a NamingContext</p>
-          <code type="erl">
-'CosNaming_NamingContext':destroy(Sc).
-          </code>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Interoperable Naming Service</title>
-    <marker id="interop_ns"></marker>
-    <p>The OMG specifies URL schemes, which represent a CORBA object and a CORBA object
-      bound in a NamingContext, for resolving references from other ORB:s. As of today,
-      three schemes are defined:</p>
-    <list type="bulleted">
-      <item>IOR</item>
-      <item>corbaloc</item>
-      <item>corbaname</item>
-    </list>
-
-    <section>
-      <title>IOR</title>
-      <p>A stringified IOR is a valid URL format but difficult for humans to handle
-        through non-electronic means. This URL format does not depend on a specific
-        Name Service and, thus, is robust and insulates the client from the encapsulated
-        transport information and object key used to reference the object.</p>
-    </section>
-
-    <section>
-      <title>corbaloc</title>
-      <p>The notation of this scheme is similar to the more well known URL <c>HTTP</c>, and
-        the full <c>corbaloc</c> BNF is:</p>
-      <code type="none"><![CDATA[
-<corbaloc>            =  "corbaloc:"<obj_addr_list>["/"<key_string>] 
-<obj_addr_list>       = [<obj_addr>","]*<obj_addr> 
-<obj_addr>            = <prot_addr> | <future_prot_addr> 
-<prot_addr>           = <rir_prot_addr> | <iiop_prot_addr> 
-<rir_prot_addr>       = <rir_prot_token>":"  
-<rir_prot_token>      = rir  
-<future_prot_addr>    = <future_prot_id><future_prot_addr>
-<future_prot_id>      = <future_prot_token>":" 
-<iiop_prot_addr>      = <iiop_id><iiop_addr>
-<iiop_id>             = <iiop_default> | <iiop_prot_token>":"  
-<iiop_default>        = ":"  
-<iiop_prot_token>     = "iiop"  
-<iiop_addr>           = <version><host>[":"<port>] 
-<host>                = <DNS-style Host Name> | <ip_v4_address> | "["<ip_v6_address>"]"
-<version>             = <major>"."<minor>"@"  | empty_string 
-<port>                = number 
-<major>               = number 
-<minor>               = number
-<DNS-style Host Name> = string
-<ip_v4_address>       = string
-<ip_v6_address>       = string
-<key_string>          = for example NameService
-      ]]></code>
-      <p>The <c>corbaloc</c> scheme consists of 3 parts:</p>
-      <list type="bulleted">
-        <item>Protocol - as of today <c>iiop</c> or <c>rir</c> is supported.
-         Using <c>rir</c> means that we will resolve the given Key locally, i.e.,
-         the same as using <c>corba:resolve_initial_references("NameService").</c></item>
-        <item>IIOP address - this address can be divided into <c>Version</c>, <c>Host</c> 
-         and <c>Port</c>. If the version or port are left out they will be set to the default
-         values <c>1.0</c> and <c>2809</c> respectively.</item>
-        <item>KeyString - an object key, e.g., "NameService". If no Key is 
-         supplied the default value "NameService" will be used.</item>
-      </list>
-      <p>A <c>corbaloc</c> can be passed used together with 
-        <c>corba:string_to_object("corbaloc::[email protected]:4001/NameService")</c> or set as the 
-        configuration variables <c>orbInitilRef</c> or <c>orbDefaultInitilRef</c> and calling
-        <c>corba:resolve_initial_references("NameService")</c>. For more information see the Orber
-        installation chapter. <c>corbaloc</c> can also be used together with <c>corbaname</c>
-        to gain an easy access to a Name Service.</p>
-      <p>Currently, the OMG defines a set of reserved keys and the type of object,
-        listed below, they should be associated with. The <c>NameService</c>
-        key may <em>not</em> be changed in Orber. If you want to add one of the
-        reserved keys as an initial service, simply use:</p>
-      <code type="erl">
-1> Factory = cosNotificationApp:start_global_factory().
-2> corba:add_initial_service("NotificationService", Factory).
-      </code>
-      <p>This object can then be easily resolved by any other ORB, supporting 
-        the Interoperable Naming Service, by using:</p>
-      <code type="erl">
-3> NF = corba:string_to_object("corbaloc::[email protected]:4001/NotificationService").
-      </code>
-      <table>
-        <row>
-          <cell align="center" valign="middle"><em>String Name</em></cell>
-          <cell align="center" valign="middle"><em>Object Type</em></cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">RootPOA</cell>
-          <cell align="left" valign="middle">PortableServer::POA</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">POACurrent</cell>
-          <cell align="left" valign="middle">PortableServer::Current</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">InterfaceRepository</cell>
-          <cell align="left" valign="middle">CORBA::Repository</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">NameService</cell>
-          <cell align="left" valign="middle">CosNaming::NamingContext</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">TradingService</cell>
-          <cell align="left" valign="middle">CosTrading::Lookup</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">SecurityCurrent</cell>
-          <cell align="left" valign="middle">SecurityLevel1::Current/SecurityLevel2::Current</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">TransactionCurrent</cell>
-          <cell align="left" valign="middle">CosTransaction::Current</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">DynAnyFactory</cell>
-          <cell align="left" valign="middle">DynamicAny::DynAnyFactory</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">ORBPolicyManager</cell>
-          <cell align="left" valign="middle">CORBA::PolicyManager</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">PolicyCurrent</cell>
-          <cell align="left" valign="middle">CORBA::PolicyCurrent</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">NotificationService</cell>
-          <cell align="left" valign="middle">CosNotifyChannelAdmin::EventChannelFactory</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">TypedNotificationService</cell>
-          <cell align="left" valign="middle">CosTypedNotifyChannelAdmin::TypedEventChannelFactory</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">CodecFactory</cell>
-          <cell align="left" valign="middle">IOP::CodecFactory</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">PICurrent</cell>
-          <cell align="left" valign="middle">PortableInterceptors::Current</cell>
-        </row>
-        <tcaption>Currently reserved key strings</tcaption>
-      </table>
-    </section>
-
-    <section>
-      <title>corbaname</title>
-      <p>The <c>corbaname</c> URL scheme is an extension of the <c>corbaloc</c> scheme, and
-        the full <c>corbaname</c> BNF is:</p>
-      <code type="none"><![CDATA[
-<corbaname>     = "corbaname:"<obj_addr_list>["/"<key_string>]["#"<string_name>] 
-<obj_addr_list> = as described above.
-<key_string>    = as described above.
-      ]]></code>
-      <p>The <c>string_name</c>, concatenated to the <c>corbaloc</c> string, identifies
-        a binding in a naming context. A name component consists of two parts, i.e.,
-        <c>id</c> and <c>kind</c>, which is represented as follows:</p>
-      <table>
-        <row>
-          <cell align="center" valign="middle"><em>String Name</em></cell>
-          <cell align="center" valign="middle"><em>Name Sequence</em></cell>
-          <cell align="center" valign="middle"><em>Comment</em></cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">"id1/./id3.kind3"</cell>
-          <cell align="left" valign="middle">[{"id1",""},{"",""},{"id3","kind3"}]</cell>
-          <cell align="left" valign="middle">The first component has no kind defined while the second component's both fields are empty.</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">"id1//id3.kind3"</cell>
-          <cell align="left" valign="middle">ERROR</cell>
-          <cell align="left" valign="middle">Not allowed, must insert a '.' between the '//'.</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">"id1.kind1/."</cell>
-          <cell align="left" valign="middle">[{"id1","kind1"},{"",""}]</cell>
-          <cell align="left" valign="middle">The first component's fields are both set while the second component's both fields are empty.</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">"id1.kind1/id2."</cell>
-          <cell align="left" valign="middle">ERROR</cell>
-          <cell align="left" valign="middle">An Id with a trailing '.' is not allowed.</cell>
-        </row>
-        <row>
-          <cell align="left" valign="middle">"i\\/d1/i\\.d2"</cell>
-          <cell align="left" valign="middle">[{"i/d1",""},{"i.d2",""}]</cell>
-          <cell align="left" valign="middle">Since '.' and '/' are used to separate the components, these tokens must be escaped to be correctly converted.</cell>
-        </row>
-        <tcaption>Stringified Name representation</tcaption>
-      </table>
-      <p>After creating a stringified Name we can either use:</p>
-      <code type="erl">
-NameStr = "org.erlang",
-NS      = corba:resolve_initial_references("NameService"),
-Obj     = 'CosNaming_NamingContextExt':resolve_str(NS, NameStr),
-      </code>
-      <p>or concatenate the Name String using:</p>
-      <code type="erl">
-NameStr = "Swedish/Soccer/Champions",
-Address = "corbaname:iiop:[email protected]:2000/NameService",
-NS      = corba:resolve_initial_references("NameService"),
-URLStr  = 'CosNaming_NamingContextExt':to_url(NS, Address, NameStr),
-Obj     = corba:string_to_object(URLStr),
-      </code>
-      <p>Using the first alternative, the configuration variables <c>orbInitilRef</c> and
-        <c>orbDefaultInitilRef</c>, will determine which other ORB's or the local
-        Name Service Orber will try to resolve the given string from. The second
-        alternative allows us to override any settings of the configuration variables.</p>
-      <p>The function <c>to_url/3</c> will perform any necessary escapes compliant with
-        IETF/RFC 2396. US-ASCII alphanumeric characters and 
-        <c><![CDATA["," | "/" | ":" | "?" | "@" | "&" | "=" | "+" | "$" | ";" | "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"]]></c>
-        are not escaped.</p>
-    </section>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_orber_kernel.xml b/lib/orber/doc/src/ch_orber_kernel.xml
deleted file mode 100644
index 396e1360fd..0000000000
--- a/lib/orber/doc/src/ch_orber_kernel.xml
+++ /dev/null
@@ -1,103 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>1999</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>The Orber Application</title>
-    <prepared></prepared>
-    <docno></docno>
-    <date>1998-10-05</date>
-    <rev></rev>
-    <file>ch_orber_kernel.xml</file>
-  </header>
-
-  <section>
-    <title>ORB Kernel and IIOP </title>
-    <p>This chapter gives a brief overview of the ORB and its relation
-      to objects in a distributed environment and the usage of Domains
-      in Orber.
-      Also Internet-Inter ORB Protocol (<term id="IIOP"><termdef>Internet-Inter ORB Protocol</termdef></term>) is discussed and how this
-      protocol facilitates communication between ORBs to
-      allow the accessory of persistent server objects in Erlang. </p>
-  </section>
-
-  <section>
-    <title>The Object Request Broker (ORB)</title>
-    <p>An ORB kernel can be best described as the middle-ware, which
-      creates relationships between clients and servers, but is
-      defined by its interfaces.  This allows transparency for the
-      user, as they do not have to be aware of where the requested
-      object is located. Thus, the programmer can work with any other
-      platform provided that an IDL mapping and interfaces exist. 
-      </p>
-    <p>The IDL mapping which is described in a later chapter is the
-      translator between other platforms, and languages. However, it
-      is the ORB, which provides  objects with a structure by which
-      they can communicate with other objects.
-      </p>
-    <p>ORBs intercept and direct messages from one object, pass this
-      message using IIOP to another ORB, which then directs the
-      message to the indicated object.
-      </p>
-    <p>An ORB is the base on which interfaces, communication stubs
-      and mapping can be built to enable communication between
-      objects. Orber uses <term id="domains"><termdef>A domain allows a more efficient communication protocol to be used between objects not on the same node without the need of an ORB</termdef></term>to group objects of different nodes
-      </p>
-    <p>How the ORB provides communication is shown very simply in figure 1 below: </p>
-    <marker id="theORB"></marker>
-    <image file="theORB.gif">
-      <icaption>
-Figure 1: How the Object Request Broker works.</icaption>
-    </image>
-    <p>The domain in Orber  gives an extra aspect to the distributed object
-      environment as each domain has one ORB, but it is distributed over
-      a number of object in different nodes. The domain binds objects on
-      nodes  more closely than distributed objects in different domains.  The
-      advantage of a domain is that a faster communication  exists between
-      nodes and objects of the same domain. An internal communication protocol
-      (other than IIOP)  allows a
-      more efficient communication between these objects. </p>
-    <note>
-      <p>Unlike objects, domains can only have one name
-        so that no communication ambiguities exist between  domains.</p>
-    </note>
-  </section>
-
-  <section>
-    <title>Internet Inter-Object Protocol (IIOP)</title>
-    <p>IIOP is a communication protocol developed by the OMG to
-      facilitate communication in a distributed object-oriented
-      environment.
-      </p>
-    <p>Figure 2 below demonstrates how IIOP works between objects:</p>
-    <marker id="iiop"></marker>
-    <image file="iiop.gif">
-      <icaption>
-Figure 2: IIOP communication between domains and objects.</icaption>
-    </image>
-    <note>
-      <p>Within the Orber domains the objects communicate without
-        using the IIOP.  However,  the user is unaware of the difference in protocols, as this difference is not visible. </p>
-    </note>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_orberweb.xml b/lib/orber/doc/src/ch_orberweb.xml
deleted file mode 100644
index c9dcc382e6..0000000000
--- a/lib/orber/doc/src/ch_orberweb.xml
+++ /dev/null
@@ -1,221 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>2001</year><year>2017</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>OrberWeb</title>
-    <prepared>Nick</prepared>
-    <docno></docno>
-    <date>2001-11-22</date>
-    <rev></rev>
-    <file>ch_orberweb.xml</file>
-  </header>
-
-  <section>
-    <title>Using OrberWeb</title>
-    <p><c>OrberWeb</c> is intended to make things easier when developing and 
-      testing applications using <c>Orber</c>. The user is able to interact
-      with <c>Orber</c> via a GUI by using a web browser.</p>
-    <p><c>OrberWeb</c> requires that the application <c>WebTool</c> is available and
-      started on at least one node; if so <c>OrberWeb</c> can usually be used to
-      to access <c>Orber</c> nodes supporting the Interoperable Naming 
-      Service. How to start OrberWeb is described in
-      <seealso marker="ch_orberweb#startorberweb">Starting OrberWeb</seealso></p>
-    <p>The <c>OrberWeb</c> GUI consists of a <em>Menu Frame</em> and a 
-      <em>Data Frames</em>.</p>
-
-    <section>
-      <title>The Menu Frame</title>
-      <p>The menu frame consists of:</p>
-      <list type="bulleted">
-        <item><em>Node List</em> - which node to access.</item>
-        <item><em>Configuration</em> - see how Orber on the current node is configured.</item>
-        <item><em>Name Service</em> - browse the NameService and add/remove a Context/Object.</item>
-        <item><em>IFR Types</em> - see which types are registered in IFR.</item>
-        <item><em>Create Object</em> - create a new object and, possibly, store it in the NameService.</item>
-      </list>
-      <p></p>
-      <marker id="menuframe"></marker>
-      <image file="menuframe.gif">
-        <icaption>The Menu Frame.</icaption>
-      </image>
-      <p>Which nodes we can access is determined by what is returned when invoking <c>[node()|nodes()]</c>.
-        If you cannot see a desired node in the list, you have to call <c>net_adm:ping(Node)</c>.
-        But this requires that the node is started with the distribution switched on
-        (e.g. <c>erl -sname myNode</c>); this also goes for the node <c>OrberWeb</c> is running on.</p>
-    </section>
-
-    <section>
-      <title>The Configuration Data Frame</title>
-      <p>When accessing the <em>Configuration</em> page OrberWeb presents a table containing the
-        <seealso marker="ch_install#config">configuration settings</seealso> for the target node.</p>
-      <p></p>
-      <marker id="dataframe3"></marker>
-      <image file="dataframe3.gif">
-        <icaption>Configuration Settings.</icaption>
-      </image>
-      <p>It is also possible to change those configuration parameters which can be changed when Orber
-        is already started. The Key-Value pairs is given as a list of tuples, e.g.,
-        <em>[{orber_debug_level, 5}, {iiop_timeout, 60}, {giop_version, {1,2}}]</em>. If one tries to update a parameter
-        which may not be changed an error message will be displayed.</p>
-    </section>
-
-    <section>
-      <title>The IFR Data Frame</title>
-      <p>All types registered in the IFR (Interface Repository) which have an associated IFR-id
-        can be viewed via the IFR Data Frame. This gives the user an easy way to confirm that
-        all necessary IDL-specifications have been properly registered. All available types are
-        listed when choosing <c>IFR Types</c> in the menu frame:</p>
-      <p></p>
-      <marker id="dataframe1"></marker>
-      <image file="dataframe1.gif">
-        <icaption>Select Type.</icaption>
-      </image>
-      <p>After selecting a type all definitions of that particular type will be displayed. If no such
-        bindings exists the table will be empty.</p>
-      <p>Since Orber adds definitions to the IFR when it is installed (e.g. CosNaming), not only
-        types defined by the user will show up in the table. In the figure below you find the
-        the NameService exceptions listed.</p>
-      <p></p>
-      <marker id="dataframe2"></marker>
-      <image file="dataframe2.gif">
-        <icaption>List Registered Exceptions.</icaption>
-      </image>
-    </section>
-
-    <section>
-      <title>The NameService Data Frame</title>
-      <p>The NameService main purpose is to make possible to bind object references, which
-        can client applications can resolve and invoke operations on. Initially, the NameService
-        is empty. The most common scenario, is that user applications create Contexts and add objects
-        in the NameService. OrberWeb allows the user to do the very same thing.</p>
-      <p>When referencing an object or context you must use stringified NameComponents.
-        For more information see the <seealso marker="ch_naming_service">Interoperable Naming Service</seealso>.
-        In the following example we will use the string <em>org/erlang/TheObjectName</em>, where
-        <em>org</em> and <em>erlang</em> will be contexts and <em>TheObjectName</em>
-        the name the object will be bound to.</p>
-      <p>Since the NameService is empty in the beginning, the only thing we can do is creating
-        a new context. Simply write <em>org</em> in the input field and press <c>New Context</c>.
-        If OrberWeb was able to create the context or not, is shown in the completion message. 
-        If successful, just press the <c>Go Back</c> button. Now, a link named <em>org</em> should
-        be listed in the table. In the right column the context type is displayed. Contexts are
-        associated with <em>ncontext</em> and objects with <em>nobject</em>.</p>
-      <p></p>
-      <marker id="dataframe5"></marker>
-      <image file="dataframe5.gif">
-        <icaption>Add a New Context.</icaption>
-      </image>
-      <p>To create the next level context (i.e. erlang), simply follow the link and repeat the procedure.
-        If done correctly, a table containing the same data as the following figure should be the result 
-        if you follow the <em>erlang</em> link. Note, that the path is displayed in the yellow
-        field.</p>
-      <p></p>
-      <p>If a context does not contain any sub-contexts or object bindings, it is possible to
-        delete the context. If these requirements are met, a <c>Delete Context</c> button will appear.
-        A completion status message will be displayed after deleting the context.</p>
-      <p></p>
-      <marker id="dataframe6"></marker>
-      <image file="dataframe6.gif">
-        <icaption>Delete Context.</icaption>
-      </image>
-      <p>Now it is possible to bind an object using the complete name string. To find out how this is
-        done using OrberWeb see <seealso marker="ch_orberweb#create">Object Creation</seealso>.
-        For now, we will just assume that an object have been created and bound as <em>TheObjectName</em>. </p>
-      <p></p>
-      <marker id="dataframe7"></marker>
-      <image file="dataframe7.gif">
-        <icaption>Object Stored in the NameService.</icaption>
-      </image>
-      <p>If you follow the <em>TheObjectName</em> link, data about the bound object will be
-        presented. Note, depending on which type of object it is, the information given differs.
-        It would, for example, not be possible to display a Pid for all types of objects since
-        it might reside on a Java-ORB. In the figure below a CosNotification FilterFactory have
-        been bound under the name <em>org/erlang/TheObjectName</em>.</p>
-      <p></p>
-      <marker id="dataframe8"></marker>
-      <image file="dataframe8.gif">
-        <icaption>Object Data.</icaption>
-      </image>
-      <p>OrberWeb also makes it possible to remove a binding and dispose the associated object.
-        Pressing <em>Unbind</em> the binding will be removed but the object will still exist. 
-        But, if the <em>Unbind and Dispose</em> button is pressed, the binding will be removed
-        and the object terminated.</p>
-    </section>
-
-    <section>
-      <title>The Object Creation Data Frame</title>
-      <marker id="create"></marker>
-      <p>This part makes it possible to create a new object and, if wanted, store it the
-        NameService.</p>
-      <p></p>
-      <marker id="dataframe4"></marker>
-      <image file="dataframe4.gif">
-        <icaption>Create a New Object.</icaption>
-      </image>
-      <list type="bulleted">
-        <item><em>Module</em> - simply type the name of the module of the object type
-         you want to create. If the module begins with a capital letter, we normally must
-         write <c>'Module_Interface'</c>. But, when using OrberWeb, you shall <em>NOT</em>.
-         Since we cannot create linked objects this is not an option.</item>
-        <item><em>Arguments</em> - the supplied arguments must be written as a single Erlang term.
-         That is, as a list or tuple containing other Erlang terms. The arguments will be 
-         passed to the <c>init</c> function of the object. It is, however, not possible
-         to use Erlang records. If OrberWeb is not able to parse the arguments, an error message
-         will be displayed. If left empty, an empty list will be passed.</item>
-        <item><em>Options</em> - the options can be the ones listed under 
-        <seealso marker="Module_Interface">Module_Interface</seealso> in Orber's Reference manual.
-         Hence, they are not further described here. But, as an example, in the figure above
-         we started the object as globally registered. If no options supplied the object
-         will be started as default.</item>
-        <item><em>Name String</em> - if left empty the object will <em>not</em> be registered in the 
-         NameService. Hence, it is important that you can access the object in another way,
-         otherwise a zombie process is created. In the previous section we used the name string
-        <em>org/erlang/TheObjectName</em>. If we choose the same name here, the listed contexts
-         (i.e. <em>org</em> and <em>erlang</em>) must be created <em>before</em> we can create
-         and bind the object to <em>TheObjectName</em>. If this requirement is not met, OrberWeb
-         cannot bind the object. Hence, the object will be terminated and an error message
-         displayed.</item>
-        <item><em>Operation to use</em> - which option choosed will determine the behavior of OrberWeb.
-         If you choose <em>bind</em> and a binding already exists an error message will be 
-         displayed and the newly started object terminated. But if you choose <em>rebind</em>
-         any existing binding will over-written.</item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Starting OrberWeb</title>
-    <marker id="startorberweb"></marker>
-    <p>You may choose to start OrberWeb on node, on which Orber is running or not. But
-      the Erlang distribution must be started (e.g. by using -sname aNodeName). Now, all 
-      you have to do is to invoke:</p>
-    <code type="none">    
-erl> webtool:start().
-WebTool is available at http://localhost:8888/
-Or  http://127.0.0.1:8888/
-    </code>
-    <p>Type one of the URL:s in your web-browser. If you want to access the WebTool application
-      from different machine, just replace <c>localhost</c> with its name. For more information,
-      see the WebTool documentation.</p>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_security.xml b/lib/orber/doc/src/ch_security.xml
deleted file mode 100644
index 151e417079..0000000000
--- a/lib/orber/doc/src/ch_security.xml
+++ /dev/null
@@ -1,96 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>1999</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>How to use security in Orber</title>
-    <prepared></prepared>
-    <docno></docno>
-    <date>1999-09-01</date>
-    <rev></rev>
-    <file>ch_security.xml</file>
-  </header>
-
-  <section>
-    <title>Security in Orber</title>
-
-    <section>
-      <title>Introduction</title>
-      <p>Orber SSL provides authentication, privacy and integrity for your
-        Erlang applications. Based on the Secure Sockets Layer protocol, the
-        Orber SSL ensures that your Orber clients and servers can
-        communicate securely over any network. 
-        This is done by tunneling IIOP through an SSL connection. To get
-        the node secure you will also need to have a firewall which
-        only lets through connections to certain ports.</p>
-    </section>
-
-    <section>
-      <title>Enable Usage of Secure Connections</title>
-      <p>To enable a secure Orber domain you have to set the configuration variable 
-        <em>secure</em> which currently only can have one of two values;
-        <em>no</em> if no security for IIOP should be used and <em>ssl</em> if 
-        secure connections is needed (<em>ssl</em> is currently the only supported 
-        security mechanism).</p>
-      <p>The default is no security.</p>
-    </section>
-
-    <section>
-      <title>Configurations when Orber is Used on the Server Side</title>
-      <p>There is a variable to conficure Orber's SSL behavior on the server side.</p>
-      <list type="bulleted">
-        <item><em>ssl_server_options</em> - which is a list of options to ssl. 
-        See the <seealso marker="ssl:ssl">SSL</seealso> application for further 
-	descriptions on these options.</item>
-      </list>
-      <p>There also exist an API function for accessing the value of this variable:</p>
-      <list type="bulleted">
-        <item>orber:ssl_server_options/0</item>
-      </list>
-    </section>
-
-    <section>
-      <title>Configurations when Orber is Used on the Client Side</title>
-      <p>When the Orber enabled application is the client side in the secure connection the 
-        different configurations can be set per client process instead and not for the whole domain
-        as for incoming calls.</p>
-      <p>There is a variable to set default values for the domain but they can be changed 
-        per client process.</p>
-      <list type="bulleted">
-        <item><em>ssl_client_options</em> - which is a list of options to ssl.
-        See the <seealso marker="ssl:ssl">SSL</seealso> application for further 
-	descriptions on these options.</item>
-      </list>
-      <p>There also exist two API functions for accessing and changing the values of this 
-        variable in the client processes.</p>
-      <p>Access function:</p>
-      <list type="bulleted">
-        <item>orber:ssl_client_options/0</item>
-      </list>
-      <p>Modify function:</p>
-      <list type="bulleted">
-        <item>orber:set_ssl_client_options/1</item>
-      </list>
-    </section>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/ch_stubs.xml b/lib/orber/doc/src/ch_stubs.xml
deleted file mode 100644
index 9290c127f9..0000000000
--- a/lib/orber/doc/src/ch_stubs.xml
+++ /dev/null
@@ -1,284 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>1999</year><year>2017</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>Orber Stubs/Skeletons</title>
-    <prepared></prepared>
-    <docno></docno>
-    <date>1999-09-03</date>
-    <rev>A</rev>
-    <file>ch_stubs.xml</file>
-  </header>
-
-  <section>
-    <title>Orber Stubs and Skeletons Description</title>
-    <p>This example describes the API and behavior of Orber stubs and skeletons.
-      </p>
-
-    <section>
-      <title>Server Start</title>
-      <p>Orber servers can be started in several ways. The chosen start functions determines
-        how the server can be accessed and its behavior.
-        </p>
-      <p>Using <c>Module_Interface:oe_create()</c> or <c>oe_create_link()</c>:
-        </p>
-      <list type="bulleted">
-        <item>No initial data can be passed.</item>
-        <item>Cannot be used as a supervisor child start function.</item>
-        <item>Only accessible through the object reference returned by the start function.
-         The object reference is no longer valid if the server dies and is restarted.</item>
-      </list>
-      <p>Using <c>Module_Interface:oe_create(Env)</c> or <c>oe_create_link(Env)</c>:</p>
-      <list type="bulleted">
-        <item>Initial data can be passed using <c>Env</c>.</item>
-        <item>Cannot be used as a supervisor child start function.</item>
-        <item>Only accessible through the object reference returned by the start function.
-         The object reference is no longer valid if the server dies and is restarted.</item>
-      </list>
-      <p>Using <c>Module_Interface:oe_create(Env, Options)</c>:</p>
-      <list type="bulleted">
-        <item>Initial data can be passed using <c>Env</c>.</item>
-        <item>Cannot be used as a supervisor child start function.</item>
-        <item>Accessible through the object reference returned by the start function. If the option 
-        <c>{regname, RegName}</c> is used the object reference stays valid even if the 
-         server has been restarted.</item>
-        <item>If the options <c>{persistent, true}</c> and <c>{regname, {global, Name}}</c> is used, 
-         the result from an object invocation will be the exception 'OBJECT_NOT_EXIST' 
-         only if the object has terminated with reason 
-        <c>normal</c> or <c>shutdown</c>. If the object is in the process of restarting, the result 
-         will be <c>{error, Reason}</c> or a system exception is raised.</item>
-        <item>The option <c>{pseudo, true}</c> makes it possible to start create non-server objects.
-         There are, however, some limitations, which are further described in the
-        <c>Pseudo objects</c> section.</item>
-      </list>
-      <p>Using <c>Module_Interface:oe_create_link(Env, Options)</c>:</p>
-      <list type="bulleted">
-        <item>Initial data can be passed using <c>Env</c>.</item>
-        <item>Can be used as a supervisor child start function if the option <c>{sup_child, true}</c> used.</item>
-        <item>Accessible through the object reference returned by the start function. If the option 
-        <c>{regname, RegName}</c> is used the object reference stays valid even if the 
-         server has been restarted.</item>
-        <item>If the options <c>{persistent, true}</c> and <c>{regname, {global, Name}}</c> is used, 
-         the result from an object invocation will be the exception 'OBJECT_NOT_EXIST' 
-         only if the object has terminated with reason 
-        <c>normal</c> or <c>shutdown</c>. If the object is in the process of restarting, the result 
-         will be <c>{error, Reason}</c> or a system exception is raised.</item>
-        <item>For starting a server as a supervisor child you should use the options 
-        <c>[{persistent, true}, {regname, {global, Name}}, {sup_child, true}]</c> and of type <em>transient</em>.
-         This configuration allows you to delegate restarts to the supervisor and still be able to
-         use the same object reference and be able to see if the server is permanently terminated.
-         Please note you must use <em>supervisor/stdlib-1.7</em> or later and that the it returns 
-        <c>{ok, Pid, Object}</c> instead of just <c>Object</c>.</item>
-        <item>Using the option <c>{pseudo, true}</c> have the same effect as using
-        <c>oe_create/2</c>.</item>
-      </list>
-      <warning>
-        <p>To avoid flooding Orber with old object references start erlang using the flag 
-          <em>-orber objectkeys_gc_time Time</em>, which will remove all object references
-          related to servers being dead for Time seconds. To avoid extra overhead, i.e., performing
-          garbage collect if no persistent objects are started, the objectkeys_gc_time default value 
-          is <em>infinity</em>. For more information, see the orber and corba documentation.</p>
-      </warning>
-      <warning>
-        <p>Orber still allow <c>oe_create(Env, {Type,RegName})</c> and <c>oe_create_link(Env, {Type,RegName})</c> to be used,
-          but may not in future releases.</p>
-      </warning>
-    </section>
-
-    <section>
-      <title>Pseudo Objects</title>
-      <p>This section describes Orber pseudo objects.
-        </p>
-      <p>The Orber stub can be used to start a <c>pseudo object</c>, which will create a non-server implementation.
-        A pseudo object introduce some limitations:</p>
-      <list type="bulleted">
-        <item>The functions <c>oe_create_link/2</c> is equal to <c>oe_create/2</c>, i.e.,
-         no link can or will be created.</item>
-        <item>The <c>BIF:s self()</c> and <c>process_flag(trap_exit,true)</c> behaves incorrectly.</item>
-        <item>The <c>IC</c> option <c>{{impl, "M::I"}, "other_impl"}</c> has no effect. The call-back
-         functions must be implemented in a file called <c>M_I_impl.erl</c></item>
-        <item>The call-back functions must be implemented as if the <c>IC</c> option 
-        <c>{this, "M::I"}</c> was used.</item>
-        <item>The gen_server <c>State</c> changes have no effect. The user can provide information via
-         the <c>Env</c> start parameter and the State returned from <c>init/2</c> will be the State
-         passed in following invocations.</item>
-        <item>The server reply <c>Timeout</c> has no effect.</item>
-        <item>The compile option <c>from</c> has no effect.</item>
-        <item>The option <c>{pseudo, true}</c> overrides all other start options.</item>
-        <item>Only the functions, besides own definitions, <c>init/2</c> (called via oe_create*/2) and 
-        <c>terminate/2</c> (called via corba:dispose/1) must be implemented.</item>
-      </list>
-      <p>By adopting the rules for <c>pseudo</c> objects described above we can use <c>oe_create/2</c>
-        to create <c>server</c> or <c>pseudo</c> objects, by excluding or including the 
-        option <c>{pseudo, true}</c>, without changing the call-back module.</p>
-      <p>To create a pseudo object do the following:</p>
-      <code type="none">
-fingolfin 127> erl 
-Erlang (BEAM) emulator version 4.9
- 
-Eshell V4.9  (abort with ^G)
-1> ic:gen(myDefinition, [{this, "MyModule::MyInterface"}]).
-Erlang IDL compiler version 20
-ok
-2> make:all().
-Recompile: oe_MyDefinition
-Recompile: MyModule_MyInterface
-Recompile: MyModule_MyInterface_impl
-up_to_date
-3> PseudoObj = MyModule_MyInterface:oe_create(Env, [{pseudo, true}]).
-      </code>
-      <p>The call-back functions must be implemented as <c>MyFunction(OE_THIS, State, Args)</c>,
-        and called by <c>MyModule_MyInterface:MyFunction(PseudoObj, Args)</c>.</p>
-    </section>
-
-    <section>
-      <title>Call-back Module</title>
-      <p>This section provides an example of how a call-back module may be implemented.</p>
-      <note>
-        <p>Arguments and Replies are determined by the IDL-code and, hence, not
-          further described here.</p>
-      </note>
-      <code type="erl">
-%%%-----------------------------------------------------------
-%%% File    : Module_Interface_impl.erl
-%%% Author  : 
-%%% Purpose : 
-%%% Created : 
-%%%-----------------------------------------------------------
- 
--module('Module_Interface_impl').
- 
-%%--------------- INCLUDES -----------------------------------
--include_lib("orber/include/corba.hrl").
--include_lib(".. ..").
- 
-%%--------------- EXPORTS-------------------------------------
-%% Arity depends on IC configuration parameters and the IDL
-%% specification.
--export([own_function/X]).
- 
- 
-%%--------------- gen_server specific ------------------------
--export([init/1, terminate/2, code_change/3, handle_info/2]).
- 
-%%------------------------------------------------------------
-%% function : server specific
-%%------------------------------------------------------------
-init(InitialData) ->
-    %% 'trap_exit' optional (have no effect if pseudo object).
-    process_flag(trap_exit,true),
-
-    %%--- Possible replies ---
-    %% Reply and await next request
-    {ok, State}.
-
-    %% Reply and if no more requests within Time the special 
-    %% timeout message should be handled in the 
-    %% Module_Interface_impl:handle_info/2 call-back function (use the 
-    %% IC option {{handle_info, "Module::Interface"}, true}).
-    {ok, State, Timeout} 
-
-    %% Return ignore in order to inform the parent, especially if it is a 
-    %% supervisor, that the server, as an example, did not start in 
-    %% accordance with the configuration data. 
-    ignore 
-    %% If the initializing procedure fails, the reason 
-    %% is supplied as StopReason.
-    {stop, StopReason}
-
-terminate(Reason, State) ->
-    ok.
-
-code_change(OldVsn, State, Extra) ->
-    {ok, NewState}.
-
-%% If use IC option {{handle_info, "Module::Interface"}, true}. 
-%% (have no effect if pseudo object).
-handle_info(Info, State) ->
-    %%--- Possible replies ---
-    %% Await the next invocation.
-    {noreply, State}.
-    %% Stop with Reason.
-    {stop, Reason, State}.
-
-%%--- two-way ------------------------------------------------
-%% If use IC option {this, "Module:Interface"} 
-%% (Required for pseudo objects)
-own_function(This, State, .. Arguments ..) ->
-%% IC options this and from
-own_function(This, From, State, .. Arguments ..) ->
-%% IC option from
-own_function(From, State, .. Arguments ..) ->
-    %% Send explicit reply to client.
-    corba:reply(From, Reply),
-    %%--- Possible replies ---
-    {noreply, State}
-    {noreply, State, Timeout}
-
- 
-%% If not use IC option {this, "Module:Interface"}
-own_function(State, .. Arguments ..) ->
-    %%--- Possible replies ---
-    %% Reply and await next request
-    {reply, Reply, State}
-
-    %% Reply and if no more requests within Time the special 
-    %% timeout message should be handled in the 
-    %% Module_Interface_impl:handle_info/2 call-back function (use the
-    %% IC option {{handle_info, "Module::Interface"}, true}).
-    {reply, Reply, State, Timeout}
-
-    %% Stop the server and send Reply to invoking object.
-    {stop, StopReason, Reply, State}
-
-    %% Stop the server and send no reply to invoking object.
-    {stop, StopReason, State}
-
-    %% Raise exception. Any changes to the internal State is lost.
-    corba:raise(Exception).
-
-%%--- one-way ------------------------------------------------
-%% If use IC option {this, "Module:Interface"}
-%% (Required for pseudo objects)
-own_function(This, State, .. Arguments ..) ->
-
-%% If not use IC option {this, "Module:Interface"}
-own_function(State, .. Arguments ..) ->
-    %%--- Possible results ---
-    {noreply, State}
-
-    %% Release and if no more requests within Time the special 
-    %% timeout message should be handled in the 
-    %% Module_Interface_impl:handle_info/2 call-back function (use the
-    %%  IC option {{handle_info, "Module::Interface"}, true}).
-    {noreply, State, Timeout}
-
-    %% Stop the server with StopReason.
-    {stop, StopReason, State}
-
-%%--------------- END OF MODULE ------------------------------
-      </code>
-    </section>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/corba.xml b/lib/orber/doc/src/corba.xml
deleted file mode 100644
index fbfb55f2f2..0000000000
--- a/lib/orber/doc/src/corba.xml
+++ /dev/null
@@ -1,454 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>1997</year><year>2017</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>corba</title>
-    <prepared></prepared>
-    <responsible></responsible>
-    <docno></docno>
-    <approved></approved>
-    <checked></checked>
-    <date>1997-06-10</date>
-    <rev>A</rev>
-  </header>
-  <module>corba</module>
-  <modulesummary>The functions on CORBA module level</modulesummary>
-  <description>
-    <p>This module contains functions that are specified on the CORBA module
-      level. It also contains some functions for creating and disposing
-      objects.</p>
-  </description>
-  <funcs>
-    <func>
-      <name>create(Module, TypeID) -> Object</name>
-      <name>create(Module, TypeID, Env) -> Object</name>
-      <name>create(Module, TypeID, Env, Optons1) -> Object</name>
-      <name>create_link(Module, TypeID) -> Object</name>
-      <name>create_link(Module, TypeID, Env) -> Object</name>
-      <name>create_link(Module, TypeID, Env, Options2) -> Reply</name>
-      <fsummary>Create and start a new server object</fsummary>
-      <type>
-        <v>Module = atom()</v>
-        <v>TypeID = string()</v>
-        <v>Env = term()</v>
-        <v>Options1 = [{persistent, Bool} | {regname, RegName} | {local_typecheck, Bool}]</v>
-        <v>Options2 = [{sup_child, Bool} | {persistent, Bool} | {regname, RegName} | {pseudo, Bool} | {local_typecheck, Bool}]</v>
-        <v>RegName = {local, atom()} | {global, term()}</v>
-        <v>Reply = #objref | {ok, Pid, #objref}</v>
-        <v>Bool = true | false</v>
-        <v>Object = #objref</v>
-      </type>
-      <desc>
-        <p>These functions start a new server object. If you start it
-          without <em>RegName</em> it can only be accessed through the 
-          returned object key. Started with a <em>RegName</em> the name is
-          registered locally or globally. </p>
-        <p><em>TypeID</em> is the repository ID of the server object type and 
-          could for example look like "IDL:StackModule/Stack:1.0". </p>
-        <p><em>Module</em> is the name of the interface API module. </p>
-        <p><em>Env</em> is the arguments passed which will be passed to the 
-          implementations <em>init</em> call-back function.</p>
-        <p>A server started with create/2, create/3 or create/4 does not care
-          about the parent, which means that the parent is not handled
-          explicitly in  the  generic process part. </p>
-        <p>A server started with create_link2, create_link/3 or create_link/4
-          is initially linked to the caller, the parent, and it will
-          terminate whenever the parent process terminates, and with the same 
-          reason as the parent. If the server traps exits, the terminate/2 
-          call-back function is called in order to clean up before the 
-          termination. These functions should be used if the server is a 
-          worker in a supervision tree.</p>
-        <p>If you use the option <c>{sup_child, true}</c> create_link/4 will return
-          <c>{ok, Pid, #objref}</c>, otherwise <c>#objref</c>, and make it possible
-          to start a server as a supervisor child (stdlib-1.7 or later).</p>
-        <p>If you use the option <c>{persistent, true}</c> you also must use the option
-          <c>{regname, {global, Name}}</c>. This combination makes it possible to tell
-          the difference between a server permanently terminated or in the process of restarting.</p>
-        <p>The option <c>{pseudo, true}</c>, allow us to create an object which is not a
-          server. Using <c>{pseudo, true}</c> overrides all other start options. 
-          For more information see section <c>Module_Interface</c>.</p>
-        <p>If a server is started using the option <c>{persistent, true}</c> the object key
-          will not be removed unless it terminates with reason <em>normal</em> or <em>shutdown</em>.
-          Hence, if persistent servers is used as supervisor children they should be <em>transient</em>
-          and the <em>objectkeys_gc_time</em> should be modified (default equals <c>infinity</c>).</p>
-        <p>The option <c>{local_typecheck, boolean()}</c>, which overrides the
-          <seealso marker="ch_install#flags">Local Typechecking</seealso>
-          environment flag, turns on or off typechecking. If activated,
-          parameters, replies and raised exceptions will be checked to ensure that
-          the data is correct, when invoking operations on CORBA Objects within
-          the same Orber domain. Due to the extra overhead, this option 
-          <em>MAY ONLY</em> be used during testing and development.</p>
-        <code type="none">
-Example: 
-
-  corba:create('StackModule_Stack', "IDL:StackModule/Stack:1.0", {10, test})
-        </code>
-      </desc>
-    </func>
-    <func>
-      <name>dispose(Object) -> ok</name>
-      <fsummary>Stop a server object</fsummary>
-      <type>
-        <v>Object = #objref</v>
-      </type>
-      <desc>
-        <p>This function is used for terminating the execution of a 
-          server object. Invoking this operation on a NIL object reference,
-          e.g., the return value of <c>corba:create_nil_objref/0</c>, always
-          return ok. For valid object references, invoking this operation
-          more than once, will result in a system exception.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_nil_objref() -> Object</name>
-      <fsummary>Stop a server object</fsummary>
-      <type>
-        <v>Object = #objref representing NIL.</v>
-      </type>
-      <desc>
-        <p>Creates an object reference that represents the NIL value.
-          Attempts to invoke operations using the returned object reference
-          will return a system exception.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_subobject_key(Object, Key) -> Result</name>
-      <fsummary>Add an Erlang term to a private key field</fsummary>
-      <type>
-        <v>Object = #objref</v>
-        <v>Key = term()</v>
-        <v>Result = #objref</v>
-      </type>
-      <desc>
-        <p>This function is used to create a subobject in a server object.
-          It can for example be useful when one wants unique access to 
-          separate rows in a mnesia or an ETS table. The <em>Result</em> is
-          an object reference that will be seen as a unique reference to 
-          the outside world but will access the same server object where one 
-          can use the <em>get_subobject_key/1</em> function to get the private
-          key value.</p>
-        <p><em>Key</em> is stored in the object reference <em>Object</em>.
-          If it is a binary it will be stored as is and otherwise it is 
-          converted to a binary before storage.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_subobject_key(Object) -> Result</name>
-      <fsummary>Fetch the contents of the private key field</fsummary>
-      <type>
-        <v>Object = #objref</v>
-        <v>Result = #binary</v>
-      </type>
-      <desc>
-        <p>This function is used to fetch a subobject key from the object 
-          reference <em>Object</em>. The result is a always a binary, if it 
-          was an Erlang term that was stored with <em>create_subobject_key/2</em>
-          one can to do <em>binary_to_term/1</em> to get the real value. </p>
-      </desc>
-    </func>
-    <func>
-      <name>get_pid(Object) -> Result</name>
-      <fsummary>Get the process id from an object key</fsummary>
-      <type>
-        <v>Object = #objref</v>
-        <v>Result = #pid | {error, Reason} | {'EXCEPTION',E}</v>
-      </type>
-      <desc>
-        <p>This function is to get the process id  from an object, which is a 
-          must when CORBA objects is started/handled in a supervisor tree. 
-          The function will throw exceptions if the key is not found or 
-          some other error occurs.</p>
-      </desc>
-    </func>
-    <func>
-      <name>raise(Exception)</name>
-      <fsummary>Generate an Erlang throw</fsummary>
-      <type>
-        <v>Exception = record()</v>
-      </type>
-      <desc>
-        <p>This function is used for raising corba exceptions as an 
-          Erlang user generated exit signal. It will throw the tuple 
-          <c>{'EXCEPTION', </c><em>Exception</em><c>}</c>.</p>
-      </desc>
-    </func>
-    <func>
-      <name>reply(To, Reply) -> true</name>
-      <fsummary>Send explicit reply to client</fsummary>
-      <type>
-        <v>To = client reference</v>
-        <v>Reply = IDL type</v>
-      </type>
-      <desc>
-        <p>This function can be used by a CORBA object to explicitly send 
-          a reply to a client that invoked a two-way operation. If this operation
-          is used, it is <em>not</em> possible to return a reply in the call-back
-          module.
-                    <br></br>
-<em>To</em> must be the <em>From</em> argument provided to the 
-          callback function, which requires that the IC option <em>from</em> 
-          was used when compiling the IDL-file.</p>
-      </desc>
-    </func>
-    <func>
-      <name>resolve_initial_references(ObjectId) -> Object</name>
-      <name>resolve_initial_references(ObjectId, Contexts) -> Object</name>
-      <fsummary>Return the object reference for the given object id</fsummary>
-      <type>
-        <v>ObjectId = string()</v>
-        <v>Contexts = [Context]</v>
-        <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
-        <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
-        <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
-        <v>Interface = string()</v>
-        <v>Options = [{Key, Value}]</v>
-        <v>Key = ssl_client_options</v>
-        <v>Value = allowed value associated with the given key</v>
-        <v>Object = #objref</v>
-      </type>
-      <desc>
-        <p>This function returns the object reference associated with the given
-          object id. Initially, only <c>"NameService"</c> is available. To add or remove
-          services use <c>add_initial_service/2</c> or <c>remove_initial_service/1</c>.</p>
-       <p>The <em>configuration</em> context is used to override the global
-           SSL client side 
-           <seealso marker="ch_install#config">configuration</seealso>.</p>
-       </desc>
-    </func>
-    <func>
-      <name>add_initial_service(ObjectId, Object) -> boolean()</name>
-      <fsummary>Add a new initial service and associate it with the given id</fsummary>
-      <type>
-        <v>ObjectId = string()</v>
-        <v>Object = #objref</v>
-      </type>
-      <desc>
-        <p>This operation allows us to add initial services, which can be accessed by 
-          using <c>resolve_initial_references/1</c> or the <c>corbaloc</c> schema.
-          If using an Id defined by the OMG, the given object must be of the
-          correct type; for more information see the
-          <seealso marker="ch_naming_service#interop_ns">Interoperable Naming Service</seealso>.
-          Returns <c>false</c> if the given id already exists.</p>
-      </desc>
-    </func>
-    <func>
-      <name>remove_initial_service(ObjectId) -> boolean()</name>
-      <fsummary>Remove association between the given id and service</fsummary>
-      <type>
-        <v>ObjectId = string()</v>
-      </type>
-      <desc>
-        <p>If we don not want a certain service to be accessible, invoking this function
-          will remove the association. Returns <c>true</c> if able to terminate the
-          binding. If no such binding existed <c>false</c> is returned.</p>
-      </desc>
-    </func>
-    <func>
-      <name>list_initial_services() -> [ObjectId]</name>
-      <fsummary>Return a list of supported object id's</fsummary>
-      <type>
-        <v>ObjectId = string()</v>
-      </type>
-      <desc>
-        <p>This function returns a list of allowed object id's.</p>
-      </desc>
-    </func>
-    <func>
-      <name>resolve_initial_references_remote(ObjectId, Address) -> Object</name>
-      <name>resolve_initial_references_remote(ObjectId, Address, Contexts) -> Object</name>
-      <fsummary>Return the object reference for the given object id</fsummary>
-      <type>
-        <v>ObjectId = string()</v>
-        <v>Address = [RemoteModifier]</v>
-        <v>RemoteModifier = string()</v>
-        <v>Contexts = [Context]</v>
-        <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
-        <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
-        <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
-        <v>Interface = string()</v>
-        <v>Options = [{Key, Value}]</v>
-        <v>Key = ssl_client_options</v>
-        <v>Value = allowed value associated with the given key</v>
-        <v>Object = #objref</v>
-      </type>
-      <desc>
-        <p>This function returns the object reference for the object id asked 
-          for.
-          The remote modifier string has the following format:
-          <c>"iiop://"&lt;host&gt;":"&lt;port&gt;</c> where <c>&lt;host&gt; = &lt;DNS hostname&gt; | 
-	  &lt;IPv4 address&gt; | "["&lt;IPv6 address&gt;"]"</c>.
-	</p>
-        <p>The <em>configuration</em> context is used to override the global
-           SSL client side 
-           <seealso marker="ch_install#config">configuration</seealso>.</p>
-        <warning>
-          <p>This operation is not supported by most ORB's. Hence, use 
-            <c>corba:string_to_object/1</c> instead.</p>
-        </warning>
-      </desc>
-    </func>
-    <func>
-      <name>list_initial_services_remote(Address) -> [ObjectId]</name>
-      <name>list_initial_services_remote(Address, Contexts) -> [ObjectId]</name>
-      <fsummary>Return a list of supported object id's</fsummary>
-      <type>
-        <v>Address = [RemoteModifier]</v>
-        <v>RemoteModifier = string()</v>
-        <v>Contexts = [Context]</v>
-        <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
-        <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
-        <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
-        <v>Interface = string()</v>
-        <v>Options = [{Key, Value}]</v>
-        <v>Key = ssl_client_options</v>
-        <v>Value = allowed value associated with the given key</v>
-        <v>ObjectId = string()</v>
-      </type>
-      <desc>
-        <p>This function returns a list of allowed object id's. 
-	  The remote modifier string has the following format: 
-	   <c>"iiop://"&lt;host&gt;":"&lt;port&gt;</c> where <c>&lt;host&gt; = &lt;DNS hostname&gt; | 
-	  &lt;IPv4 address&gt; | "["&lt;IPv6 address&gt;"]"</c>.
-	</p>
-        <p>The <em>configuration</em> context is used to override the global
-           SSL client side 
-           <seealso marker="ch_install#config">configuration</seealso>.</p>
-        <warning>
-          <p>This operation is not supported by most ORB's. Hence, avoid
-            using it.</p>
-        </warning>
-      </desc>
-    </func>
-    <func>
-      <name>object_to_string(Object) -> IOR_string</name>
-      <fsummary>Convert the object reference to the external string representation</fsummary>
-      <type>
-        <v>Object = #objref</v>
-        <v>IOR_string = string()</v>
-      </type>
-      <desc>
-        <p>This function returns the object reference as the external string 
-          representation of an IOR.</p>
-      </desc>
-    </func>
-    <func>
-      <name>string_to_object(IOR_string) -> Object</name>
-      <name>string_to_object(IOR_string, Contexts) -> Object</name>
-      <fsummary>Convert the external string representation to an object reference</fsummary>
-      <type>
-        <v>IOR_string = string()</v>
-        <v>Contexts = [Context]</v>
-        <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
-        <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
-        <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
-        <v>Interface = string()</v>
-        <v>Options = [{Key, Value}]</v>
-        <v>Key = ssl_client_options</v>
-        <v>Value = allowed value associated with the given key</v>
-        <v>Object = #objref</v>
-      </type>
-      <desc>
-        <p>This function takes a <c>corbaname</c>, <c>corbaloc</c> or an IOR on the
-          external string representation and returns the object reference.</p>
-        <p>To lookup the NameService reference, simply use:</p>
-        <code>corbaloc:iiop:[email protected]:4001/NameService</code>
-        <p>We can also resolve an object from the NameService by using:</p>
-        <code>corbaname:iiop:[email protected]:4001/NameService#org/Erlang/MyObj</code>
-        <p>To lookup the NameService reference with an IPv6 address, simply use:</p>
-        <code>corbaloc:iiop:1.2@[FEC1:0:3:0:0312:44AF:FAB1:3D01]:4001/NameService</code>
-        <p>For more information about <c>corbaname</c> and <c>corbaloc</c>, see
-          the User's Guide (Interoperable Naming Service).</p>
-        <p>The <em>configuration</em> context is used to override the global
-           SSL client side 
-           <seealso marker="ch_install#config">configuration</seealso>.</p>
-        <p>How to handle the interface context is further described in the User's Guide.</p>
-      </desc>
-    </func>
-    <func>
-      <name>print_object(Data [, Type]) -> ok | {'EXCEPTION', E} |  {'EXIT', R} | string()</name>
-      <fsummary>Print the supplied object</fsummary>
-      <type>
-        <v>Data = IOR_string | #objref (local or external) | corbaloc/corbaname string</v>
-        <v>Type = IoDevice | error_report | {error_report, Reason} | info_msg | {info_msg, Comment} | string</v>
-        <v>IoDevice = see the io-module</v>
-        <v>Reason = Comment = string()</v>
-      </type>
-      <desc>
-        <p>The object represented by the supplied data is dissected and presented
-          in a more readable form. The Type parameter is optional; if not supplied
-          standard output is used. For <c>error_report</c> and <c>info_msg</c>
-          the <c>error_logger</c> module is used, with or without Reason or Comment.
-          If the atom <c>string</c> is supplied this function will return a flat
-          list. The <c>IoDevice</c> is passed to the operation <c>io:format/2</c>.</p>
-        <p>If the supplied object is a local reference, the output is equivalent
-          to an object exported from the node this function is invoked on.</p>
-      </desc>
-    </func>
-    <func>
-      <name>add_alternate_iiop_address(Object, Host, Port) -> NewObject | {'EXCEPTION', E}</name>
-      <fsummary>Add ALTERNATE_IIOP_ADDRESS component to the supplied local object</fsummary>
-      <type>
-        <v>Object = NewObject = local #objref</v>
-        <v>Host = string()</v>
-        <v>Port = integer()</v>
-      </type>
-      <desc>
-        <p>This operation creates a new instance of the supplied object
-          containing an ALTERNATE_IIOP_ADDRESS component. Only the new instance
-          contains the new component. When this object is passed to another
-          ORB, which supports the ALTERNATE_IIOP_ADDRESS, requests will be routed
-          to the alternate address if it is not possible to communicate with
-          the main address.</p>
-        <p>The ALTERNATE_IIOP_ADDRESS component requires that IIOP-1.2 is used.
-          Hence, make sure both Orber and the other ORB is correctly configured.</p>
-        <p></p>
-        <note>
-          <p>Make sure that the given <c>Object</c> is accessible via the
-            alternate Host/port. For example, if the object is correctly started as 
-            <c>local</c> or <c>pseudo</c>, the object should be available on all
-            nodes within a multi-node Orber installation. Since only one instance
-            exists for other object types, it will not be possible to access it
-            if the node it was started on terminates.</p>
-        </note>
-      </desc>
-    </func>
-    <func>
-      <name>orb_init(KeyValueList) -> ok | {'EXIT', Reason}</name>
-      <fsummary>Configure Orber before starting it</fsummary>
-      <type>
-        <v>KeyValueList = [{Key, Value}]</v>
-        <v>Key = any key listed in the configuration chapter</v>
-        <v>Value = allowed value associated with the given key</v>
-      </type>
-      <desc>
-        <p>This function allows the user to configure Orber in, for example,
-          an Erlang shell. Orber may <em>NOT</em> be started prior to invoking
-          this operation. For more information, see
-          <seealso marker="ch_install#config">configuration settings</seealso>
-          in the User's Guide.</p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/corba_object.xml b/lib/orber/doc/src/corba_object.xml
deleted file mode 100644
index 09a4b0bc3c..0000000000
--- a/lib/orber/doc/src/corba_object.xml
+++ /dev/null
@@ -1,194 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>1997</year>
-      <year>2016</year>
-      <holder>Ericsson AB, All Rights Reserved</holder>
-    </copyright>
-    <legalnotice>
-  Licensed under the Apache License, Version 2.0 (the "License");
-  you may not use this file except in compliance with the License.
-  You may obtain a copy of the License at
- 
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
-
-  The Initial Developer of the Original Code is Ericsson AB.
-    </legalnotice>
-
-    <title>corba_object</title>
-    <prepared></prepared>
-    <responsible></responsible>
-    <docno></docno>
-    <approved></approved>
-    <checked></checked>
-    <date>1997-11-10</date>
-    <rev>A</rev>
-  </header>
-  <module>corba_object</module>
-  <modulesummary>The CORBA Object interface functions</modulesummary>
-  <description>
-    <p>This module contains the CORBA Object interface functions that can be 
-      called for all objects.</p>
-  </description>
-  <funcs>
-    <func>
-      <name>get_interface(Object) -> InterfaceDef</name>
-      <fsummary>Fetch the interface description</fsummary>
-      <type>
-        <v>Object = #objref</v>
-        <v>InterfaceDef = term()</v>
-      </type>
-      <desc>
-        <p>This function returns the full interface description for an object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>is_nil(Object) -> boolean()</name>
-      <fsummary>Return true, if the given object is a NIL object reference, otherwise false</fsummary>
-      <type>
-        <v>Object = #objref</v>
-      </type>
-      <desc>
-        <p>This function checks if the object reference has a nil object value,
-          which denotes no object. It is the reference that is tested and no 
-          object implementation is involved in the test. </p>
-      </desc>
-    </func>
-    <func>
-      <name>is_a(Object, Logical_type_id) -> Return</name>
-      <name>is_a(Object, Logical_type_id, Contexts) -> Return</name>
-      <fsummary>Return true if the target object is an, or inherit from, object of the given type</fsummary>
-      <type>
-        <v>Object = #objref</v>
-        <v>Logical_type_id = string()</v>
-        <v>Contexts = [Context]</v>
-        <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
-        <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
-        <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
-        <v>Interface = string()</v>
-        <v>Options = [{Key, Value}]</v>
-        <v>Key = ssl_client_options</v>
-        <v>Value = allowed value associated with the given key</v>
-        <v>Return = boolean() | {'EXCEPTION', E}</v>
-      </type>
-      <desc>
-        <p>The <em>Logical_type_id</em> is a string that is a share type
-          identifier (repository id). The function returns true if the object
-          is an instance of that type or an ancestor of the "most derived"
-          type of that object.</p>
-        <p>The <em>configuration</em> context is used to override the global
-           SSL client side 
-           <seealso marker="ch_install#config">configuration</seealso>.</p>
-        <p>Note: Other ORB suppliers may not support this function completely
-          according to the OMG specification. Thus, a <em>is_a</em> call may
-          raise an exception or respond unpredictable if the Object is
-          located on a remote node.</p>
-      </desc>
-    </func>
-    <func>
-      <name>is_remote(Object) -> boolean()</name>
-      <fsummary>Determine whether or not an object reference is remote</fsummary>
-      <type>
-        <v>Object = #objref</v>
-      </type>
-      <desc>
-        <p>This function returns true if an object reference is remote 
-          otherwise false. </p>
-      </desc>
-    </func>
-    <func>
-      <name>non_existent(Object) -> Return</name>
-      <name>non_existent(Object, Contexts) -> Return</name>
-      <fsummary>Return false if the target object do not exist, otherwise true</fsummary>
-      <type>
-        <v>Object = #objref</v>
-        <v>Contexts = [Context]</v>
-        <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
-        <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
-        <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
-        <v>Interface = string()</v>
-        <v>Options = [{Key, Value}]</v>
-        <v>Key = ssl_client_options</v>
-        <v>Value = allowed value associated with the given key</v>
-        <v>Return = boolean() | {'EXCEPTION', E}</v>
-      </type>
-      <desc>
-        <p>This function can be used to test if the object has been destroyed. 
-          It does this without invoking any application level code. The ORB 
-          returns true if it knows that the object is destroyed otherwise 
-          false.</p>
-        <p>The <em>configuration</em> context is used to override the global
-           SSL client side 
-           <seealso marker="ch_install#config">configuration</seealso>.</p>
-        <p>Note: The OMG have specified two different operators, <c>_not_existent</c> (CORBA version 2.0 and 2.2) and 
-          <c>_non_existent</c> (CORBA version 2.3), to be used for this function. It is not mandatory to support
-          both versions. Thus, a <em>non_existent</em> call may raise an exception or respond unpredictable 
-          if the Object is located on a remote node. Depending on which version, ORB:s you intend to
-          communicate with supports, you can either use this function or <c>not_existent/1</c>.</p>
-      </desc>
-    </func>
-    <func>
-      <name>not_existent(Object) -> Return</name>
-      <name>not_existent(Object, Contexts) -> Return</name>
-      <fsummary>Return false if the target object do not exist, otherwise true</fsummary>
-      <type>
-        <v>Object = #objref</v>
-        <v>Contexts = [Context]</v>
-        <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v>
-        <v>CtxId = ?ORBER_GENERIC_CTX_ID</v>
-        <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v>
-        <v>Interface = string()</v>
-        <v>Options = [{Key, Value}]</v>
-        <v>Key = ssl_client_options</v>
-        <v>Value = allowed value associated with the given key</v>
-        <v>Return = boolean() | {'EXCEPTION', E}</v>
-      </type>
-      <desc>
-        <p>This function is implemented due to Interoperable purposes. Behaves as
-          <c>non_existent</c> except the operator <c>_not_existent</c> is used when
-          communicating with other ORB:s.</p>
-        <p>The <em>configuration</em> context is used to override the global
-           SSL client side 
-           <seealso marker="ch_install#config">configuration</seealso>.</p>
-      </desc>
-    </func>
-    <func>
-      <name>is_equivalent(Object, OtherObject) -> boolean()</name>
-      <fsummary>Return true if the target object and the supplied object easily can be determined to be equal, otherwise false</fsummary>
-      <type>
-        <v>Object = #objref</v>
-        <v>OtherObject = #objref</v>
-      </type>
-      <desc>
-        <p>This function is used to determine if two object references are 
-          equivalent so far the ORB easily can determine. It returns 
-          <em>true</em> if the target object reference is equal to the 
-          other object reference and <em>false</em> otherwise.</p>
-      </desc>
-    </func>
-    <func>
-      <name>hash(Object, Maximum) -> int()</name>
-      <fsummary>Return a hash value based on the target object</fsummary>
-      <type>
-        <v>Object = #objref</v>
-        <v>Maximum = int()</v>
-      </type>
-      <desc>
-        <p>This function returns a hash value based on the object reference 
-          that not will change during the lifetime of the object. 
-          The <em>Maximum</em> parameter denotes the upper bound of the value.</p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/dataframe1.gif b/lib/orber/doc/src/dataframe1.gif
deleted file mode 100644
index 21bd0afbc5..0000000000
--- a/lib/orber/doc/src/dataframe1.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/dataframe2.gif b/lib/orber/doc/src/dataframe2.gif
deleted file mode 100644
index 26778932b4..0000000000
--- a/lib/orber/doc/src/dataframe2.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/dataframe3.gif b/lib/orber/doc/src/dataframe3.gif
deleted file mode 100644
index db8ffef7d1..0000000000
--- a/lib/orber/doc/src/dataframe3.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/dataframe4.gif b/lib/orber/doc/src/dataframe4.gif
deleted file mode 100644
index f64c7f3733..0000000000
--- a/lib/orber/doc/src/dataframe4.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/dataframe5.gif b/lib/orber/doc/src/dataframe5.gif
deleted file mode 100644
index 80e17945a2..0000000000
--- a/lib/orber/doc/src/dataframe5.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/dataframe6.gif b/lib/orber/doc/src/dataframe6.gif
deleted file mode 100644
index fb1c5d7827..0000000000
--- a/lib/orber/doc/src/dataframe6.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/dataframe7.gif b/lib/orber/doc/src/dataframe7.gif
deleted file mode 100644
index 1e18078f0a..0000000000
--- a/lib/orber/doc/src/dataframe7.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/dataframe8.gif b/lib/orber/doc/src/dataframe8.gif
deleted file mode 100644
index ef95c9a11f..0000000000
--- a/lib/orber/doc/src/dataframe8.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/dependent.gif b/lib/orber/doc/src/dependent.gif
deleted file mode 100644
index c65c427421..0000000000
--- a/lib/orber/doc/src/dependent.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/example_part.xml b/lib/orber/doc/src/example_part.xml
deleted file mode 100644
index 61c9524cc3..0000000000
--- a/lib/orber/doc/src/example_part.xml
+++ /dev/null
@@ -1,36 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE part SYSTEM "part.dtd">
-
-<part>
-  <header>
-    <copyright>
-      <year>2002</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-
-    </legalnotice>
-
-    <title>Service Implementation</title>
-    <prepared>Niclas Eklund</prepared>
-    <docno></docno>
-    <date>2002-06-25</date>
-    <rev>A</rev>
-  </header>
-  <description>
-    <p>This chapter describe how to implement Orber based CORBA services.</p>
-  </description>
-  <include file="ch_stubs"></include>
-</part>
-
diff --git a/lib/orber/doc/src/firewall_nat.gif b/lib/orber/doc/src/firewall_nat.gif
deleted file mode 100644
index 3a80aac724..0000000000
--- a/lib/orber/doc/src/firewall_nat.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/fixed.xml b/lib/orber/doc/src/fixed.xml
deleted file mode 100644
index ef4d1bd604..0000000000
--- a/lib/orber/doc/src/fixed.xml
+++ /dev/null
@@ -1,160 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>2002</year><year>2017</year>
-      <holder>Ericsson AB, All Rights Reserved</holder>
-    </copyright>
-    <legalnotice>
-  Licensed under the Apache License, Version 2.0 (the "License");
-  you may not use this file except in compliance with the License.
-  You may obtain a copy of the License at
- 
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
-
-  The Initial Developer of the Original Code is Ericsson AB.
-    </legalnotice>
-
-    <title>fixed</title>
-    <prepared></prepared>
-    <responsible></responsible>
-    <docno></docno>
-    <approved></approved>
-    <checked></checked>
-    <date>2002-05-22</date>
-    <rev>A</rev>
-  </header>
-  <module>fixed</module>
-  <modulesummary>the corba fixed type</modulesummary>
-  <description>
-    <p>This module contains functions that gives an interface to the CORBA fixed type.</p>
-    <p>The type <c>Fixed</c> used below is defined as:</p>
-    <code type="erl">
--record(fixed, {digits, scale, value}).
-    </code>
-    <p>where <c>digits</c> is the total amount of digits it consists of and 
-      <c>scale</c> is the number of fractional digits. The <c>value</c> field
-      contains the actual Fixed value represented as an integer. The limitations
-      of each field are:</p>
-    <list type="bulleted">
-      <item>Digits - integer(), -1 > Digits &lt; 32</item>
-      <item>Scale - integer(), -1 > Scale =&lt; Digits</item>
-      <item>Value - integer(), range (31 digits): &plusmn;9999999999999999999999999999999</item>
-    </list>
-    <p>Since the Value part is represented by an integer, it is vital that the
-      Digits and Scale values are correct. This also means that trailing zeros
-      cannot be left out in some cases:</p>
-    <list type="bulleted">
-      <item>fixed&lt;5,3> eq. 03.140d eq. 3140</item>
-      <item>fixed&lt;3,2> eq. 3.14d eq. 314</item>
-    </list>
-    <p>Leading zeros can be left out.</p>
-    <p>For your convenience, this module exports functions which handle
-      unary (<c>-</c>) and binary (<c>+-*/</c>) operations legal for the Fixed type.
-      Since a unary <c>+</c> have no effect, this module do not export such a 
-      function. Any of the binary operations may cause an overflow (i.e. more than
-      31 significant digits; leading and trailing zeros are not considered 
-      significant). If this is the case, the Digit and Scale values are adjusted
-      and the Value truncated (no rounding performed). This behavior is
-      compliant with the OMG CORBA specification. Each binary operation have
-      the following upper bounds:</p>
-    <list type="bulleted">
-      <item><em>Fixed1 + Fixed2</em> - <c><![CDATA[fixed<max(d1-s1,d2-s2) + max(s1,s2) + 1, max(s1,s2)>]]></c></item>
-      <item><em>Fixed1 - Fixed2</em> - <c><![CDATA[fixed<max(d1-s1,d2-s2) + max(s1,s2) + 1, max(s1,s2)>]]></c></item>
-      <item><em>Fixed1 * Fixed2</em> - <c><![CDATA[fixed<d1+d2, s1+s2>]]></c></item>
-      <item><em>Fixed1 / Fixed2</em> - <c><![CDATA[fixed<(d1-s1+s2) + Sinf ,Sinf >]]></c></item>
-    </list>
-    <p>A quotient may have an arbitrary number of decimal places, which is 
-      denoted by a scale of Sinf.</p>
-  </description>
-  <funcs>
-    <func>
-      <name>create(Digits, Scale, Value) -> Result</name>
-      <fsummary>Create a fixed type</fsummary>
-      <type>
-        <v>Result = Fixed Type | {'EXCEPTION', #'BAD_PARAM'{}}</v>
-      </type>
-      <desc>
-        <p>This function creates a new instance of a <c>Fixed Type</c>. If
-          the limitations is not fulfilled (e.g. overflow) an exception is
-          raised.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_typecode(Fixed) -> Result</name>
-      <fsummary>Create TypeCode representing the supplied fixed type</fsummary>
-      <type>
-        <v>Result = TypeCode | {'EXCEPTION', #'BAD_PARAM'{}}</v>
-      </type>
-      <desc>
-        <p>Returns the TypeCode which represents the supplied Fixed type.
-          If the parameter is not of the correct type, an exception is raised.</p>
-      </desc>
-    </func>
-    <func>
-      <name>add(Fixed1, Fixed2) -> Result</name>
-      <fsummary>Add the supplied Fixed types</fsummary>
-      <type>
-        <v>Result = Fixed1 + Fixed2 | {'EXCEPTION', #'BAD_PARAM'{}}</v>
-      </type>
-      <desc>
-        <p>Performs a Fixed type addition.
-          If the parameters are not of the correct type, an exception is raised.</p>
-      </desc>
-    </func>
-    <func>
-      <name>subtract(Fixed1, Fixed2) -> Result</name>
-      <fsummary>Subtract Fixed2 from Fixed1</fsummary>
-      <type>
-        <v>Result = Fixed1 - Fixed2 | {'EXCEPTION', #'BAD_PARAM'{}}</v>
-      </type>
-      <desc>
-        <p>Performs a Fixed type subtraction.
-          If the parameters are not of the correct type, an exception is raised.</p>
-      </desc>
-    </func>
-    <func>
-      <name>multiply(Fixed1, Fixed2) -> Result</name>
-      <fsummary>Multiply Fixed1 with Fixed2</fsummary>
-      <type>
-        <v>Result = Fixed1 * Fixed2 | {'EXCEPTION', #'BAD_PARAM'{}}</v>
-      </type>
-      <desc>
-        <p>Performs a Fixed type multiplication.
-          If the parameters are not of the correct type, an exception is raised.</p>
-      </desc>
-    </func>
-    <func>
-      <name>divide(Fixed1, Fixed2) -> Result</name>
-      <fsummary>Divide Fixed1 with Fixed2</fsummary>
-      <type>
-        <v>Result = Fixed1 / Fixed2 | {'EXCEPTION', #'BAD_PARAM'{}}</v>
-      </type>
-      <desc>
-        <p>Performs a Fixed type division.
-          If the parameters are not of the correct type, an exception is raised.</p>
-      </desc>
-    </func>
-    <func>
-      <name>unary_minus(Fixed) -> Result</name>
-      <fsummary>Negate the supplied Fixed Type</fsummary>
-      <type>
-        <v>Result = -Fixed | {'EXCEPTION', #'BAD_PARAM'{}}</v>
-      </type>
-      <desc>
-        <p>Negates the supplied Fixed type.
-          If the parameter is not of the correct type, an exception is raised.</p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/ifr_notes.txt b/lib/orber/doc/src/ifr_notes.txt
deleted file mode 100644
index 54f79be8cd..0000000000
--- a/lib/orber/doc/src/ifr_notes.txt
+++ /dev/null
@@ -1,53 +0,0 @@
--*-Mode: Outline;-*-
-
-* Transactions.
-  Transaction handling (or the use of mnesia:async_dirty) is not very
-  good at error checking. Code to handle errors from transactions must
-  be added. Right now it is not possible to mix atomic transactions
-  with dirty 'transactions' (i.e. async_dirty) and still check the
-  results consistently. This must be fixed if we are to read with
-  async_dirty instead of transaction, since we still want to do all
-  the writes with transaction and not async_dirty.
-  (This point might be moot. Simple reads are now done with
-  mnesia:dirty_read/1 outside of transactions).
-
-* Unresolved issues.
-  There are some places in the source code marked with '***' where the
-  code should be verified. It mostly concerns minor unresolved
-  unclarities in the specification.
-
-** orber_ifr_contained.erl
-  In move/4 there is a call to orber_ifr_contained:lookup_name/5. The
-  third argument, Levels_to_search, is set to -1, which means search
-  all contained objects. This is probably correct.
-
-** orber_ifr_interfacedef.erl
-  The function describe_interface/1 describes the interface without
-  its inherited interfaces. It is not clear whether this is correct or
-  not. It is possible to get a description of the inherited interfaces
-  by mapping describe_interface/1 on the list if interfaces returned
-  by get_base_interfaces/1. Also, since the structs
-  InterfaceDescription and FullInterfaceDescription both have a field
-  named base_interfaces, it is possible to get a description of the
-  inherited attributes by examining that field and applying a describe
-  function.
-
-** orber_ifr_orb.erl
-  create_union_tc/4 sets the fifth element in the typecode tuple to
-  -1, meaning no default case.
-
-** orber_ifr_repository.erl
-  The PrimitiveDef with kind pk_objref has an empty Id and an empty
-  Name. This is perhaps not correct.
-
-** orber_ifr_typecode.erl
-  None of the functions in this module are fully implemented and they
-  should not be used.
-
-** orber_ifr_uniondef.erl
-*** '_set_members'/2
-  What should the value of the discriminator-typecode be when updating
-  the type attribute? (CORBA 2.0, p 6-20). For now we just leave it
-  unchanged, but this is perhaps not the right thing to do.
-
-*  Exceptions should give more information about the failure.
diff --git a/lib/orber/doc/src/iiop.gif b/lib/orber/doc/src/iiop.gif
deleted file mode 100644
index d2f2fd128c..0000000000
--- a/lib/orber/doc/src/iiop.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/GridBagEx.gif b/lib/orber/doc/src/images/GridBagEx.gif
deleted file mode 100644
index 16c326d88c..0000000000
--- a/lib/orber/doc/src/images/GridBagEx.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/OpenBookIcon.gif b/lib/orber/doc/src/images/OpenBookIcon.gif
deleted file mode 100644
index 86384f7733..0000000000
--- a/lib/orber/doc/src/images/OpenBookIcon.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/blue-ball-small.gif b/lib/orber/doc/src/images/blue-ball-small.gif
deleted file mode 100644
index d4c5cde5b0..0000000000
--- a/lib/orber/doc/src/images/blue-ball-small.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/blue-ball.gif b/lib/orber/doc/src/images/blue-ball.gif
deleted file mode 100644
index edc29b786c..0000000000
--- a/lib/orber/doc/src/images/blue-ball.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/class-index.gif b/lib/orber/doc/src/images/class-index.gif
deleted file mode 100644
index 7f276bcb24..0000000000
--- a/lib/orber/doc/src/images/class-index.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/constructor-index.gif b/lib/orber/doc/src/images/constructor-index.gif
deleted file mode 100644
index 435cac4238..0000000000
--- a/lib/orber/doc/src/images/constructor-index.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/constructors.gif b/lib/orber/doc/src/images/constructors.gif
deleted file mode 100644
index d1a6ae507c..0000000000
--- a/lib/orber/doc/src/images/constructors.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/cyan-ball-small.gif b/lib/orber/doc/src/images/cyan-ball-small.gif
deleted file mode 100644
index 7f74357443..0000000000
--- a/lib/orber/doc/src/images/cyan-ball-small.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/cyan-ball.gif b/lib/orber/doc/src/images/cyan-ball.gif
deleted file mode 100644
index 97ca1f2b6e..0000000000
--- a/lib/orber/doc/src/images/cyan-ball.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/error-index.gif b/lib/orber/doc/src/images/error-index.gif
deleted file mode 100644
index 22835ff8c6..0000000000
--- a/lib/orber/doc/src/images/error-index.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/exception-index.gif b/lib/orber/doc/src/images/exception-index.gif
deleted file mode 100644
index e3830d9c52..0000000000
--- a/lib/orber/doc/src/images/exception-index.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/green-ball-small.gif b/lib/orber/doc/src/images/green-ball-small.gif
deleted file mode 100644
index 17fea5b32b..0000000000
--- a/lib/orber/doc/src/images/green-ball-small.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/green-ball.gif b/lib/orber/doc/src/images/green-ball.gif
deleted file mode 100644
index 71e1b2ec2d..0000000000
--- a/lib/orber/doc/src/images/green-ball.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/interface-index.gif b/lib/orber/doc/src/images/interface-index.gif
deleted file mode 100644
index bf93dda9e3..0000000000
--- a/lib/orber/doc/src/images/interface-index.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/magenta-ball-small.gif b/lib/orber/doc/src/images/magenta-ball-small.gif
deleted file mode 100644
index bd0584b3c6..0000000000
--- a/lib/orber/doc/src/images/magenta-ball-small.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/magenta-ball.gif b/lib/orber/doc/src/images/magenta-ball.gif
deleted file mode 100644
index 5da03b84d2..0000000000
--- a/lib/orber/doc/src/images/magenta-ball.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/method-index.gif b/lib/orber/doc/src/images/method-index.gif
deleted file mode 100644
index a05e705116..0000000000
--- a/lib/orber/doc/src/images/method-index.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/methods.gif b/lib/orber/doc/src/images/methods.gif
deleted file mode 100644
index 949e01b8a3..0000000000
--- a/lib/orber/doc/src/images/methods.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/package-index.gif b/lib/orber/doc/src/images/package-index.gif
deleted file mode 100644
index f894d4210d..0000000000
--- a/lib/orber/doc/src/images/package-index.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/red-ball-small.gif b/lib/orber/doc/src/images/red-ball-small.gif
deleted file mode 100644
index f6b3c372ca..0000000000
--- a/lib/orber/doc/src/images/red-ball-small.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/red-ball.gif b/lib/orber/doc/src/images/red-ball.gif
deleted file mode 100644
index dca9296014..0000000000
--- a/lib/orber/doc/src/images/red-ball.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/variable-index.gif b/lib/orber/doc/src/images/variable-index.gif
deleted file mode 100644
index 65cc029e72..0000000000
--- a/lib/orber/doc/src/images/variable-index.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/variables.gif b/lib/orber/doc/src/images/variables.gif
deleted file mode 100644
index e8a735399a..0000000000
--- a/lib/orber/doc/src/images/variables.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/yellow-ball-small.gif b/lib/orber/doc/src/images/yellow-ball-small.gif
deleted file mode 100644
index 8e5f57cdfc..0000000000
--- a/lib/orber/doc/src/images/yellow-ball-small.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/images/yellow-ball.gif b/lib/orber/doc/src/images/yellow-ball.gif
deleted file mode 100644
index 2b8c0bb3d6..0000000000
--- a/lib/orber/doc/src/images/yellow-ball.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/interceptor_operations.gif b/lib/orber/doc/src/interceptor_operations.gif
deleted file mode 100644
index cd72f7fcb7..0000000000
--- a/lib/orber/doc/src/interceptor_operations.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/interceptors.xml b/lib/orber/doc/src/interceptors.xml
deleted file mode 100644
index 0aade8ffb4..0000000000
--- a/lib/orber/doc/src/interceptors.xml
+++ /dev/null
@@ -1,284 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>2001</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>interceptors</title>
-    <prepared></prepared>
-    <responsible></responsible>
-    <docno></docno>
-    <approved></approved>
-    <checked></checked>
-    <date>1999-09-03</date>
-    <rev>A</rev>
-  </header>
-  <module>interceptors</module>
-  <modulesummary>Describe the functions which must be exported by any supplied Orber native interceptor.</modulesummary>
-  <description>
-    <p>This module contains the mandatory functions for user supplied native
-      interceptors and their intended behavior. See also the User's Guide.</p>
-    <warning>
-      <p>Using <c>Interceptors</c> may reduce the through-put significantly
-        if the supplied interceptors invoke expensive operations. Hence, 
-        one should always supply interceptors which cause as little overhead
-        as possible.</p>
-    </warning>
-    <warning>
-      <p>It is possible to alter the <c>Data</c>, <c>Bin</c> and <c>Args</c>
-        parameter for the <c>in_reply</c> and <c>out_reply</c>, 
-        <c>in_reply_encoded</c>, <c>in_request_encoded</c>, 
-        <c>out_reply_encoded</c> and <c>out_request_encoded</c>,
-        <c>in_request</c> and <c>out_request</c> respectively. But,
-        if it is done incorrectly, the consequences can be serious.</p>
-    </warning>
-    <note>
-      <p>The <c>Extra</c> parameter is set to 'undefined' by Orber when calling
-        the first interceptor and may be set to any Erlang term.  If an
-        interceptor change this parameter it will be passed on to the next
-        interceptor in the list uninterpreted.</p>
-    </note>
-    <note>
-      <p>The <c>Ref</c> parameter is set to 'undefined' by Orber when calling
-        <c>new_in_connection</c> or <c>new_out_connection</c> using
-        the first interceptor. The user supplied interceptor may set <c>NewRef</c>
-        to any Erlang term.  If an interceptor change this parameter it will be
-        passed on to the next interceptor in the list uninterpreted.</p>
-    </note>
-  </description>
-  <funcs>
-    <func>
-      <name>new_in_connection(Ref, PeerHost, PeerPort) -> NewRef</name>
-      <name>new_in_connection(Ref, PeerHost, PeerPort, SocketHost, SocketPort) -> NewRef</name>
-      <fsummary>Invoke when a new client ORB wants to setup a connection</fsummary>
-      <type>
-        <v>Ref    = term() | undefined</v>
-        <v>PeerHost = SocketHost = string(), e.g., "myHost@myServer" or "192.0.0.10"</v>
-        <v>PeerPort = SocketPort = integer()</v>
-        <v>NewRef = term() | {'EXIT', Reason}</v>
-      </type>
-      <desc>
-        <p>When a new connection is requested by a client side ORB this operation
-          is invoked. If more than one interceptor is supplied, e.g., 
-          <c>{native, ['myInterceptor1', 'myInterceptor2']}</c>, the return value
-          from 'myInterceptor1' is passed to 'myInterceptor2' as <c>Ref</c>.
-          Initially, Orber uses the atom 'undefined' as <c>Ref</c> parameter
-          when calling the first interceptor. The return value from the last
-          interceptor, in the example above 'myInterceptor2', is passed
-          to all other functions exported by the interceptors. Hence,
-          the <c>Ref</c> parameter can, for example, be used as a unique 
-          identifier to mnesia or ets where information/restrictions for
-          this connection is stored.</p>
-        <p>The PeerHost and PeerPort variables supplied data of
-          the client ORB which requested a new connection. SocketHost 
-          and SocketPort are the local interface and port the client
-          connected to.</p>
-        <p>If, for some reason, we do not allow the client ORB to connect
-          simply invoke <c>exit(Reason)</c>.</p>
-      </desc>
-    </func>
-    <func>
-      <name>new_out_connection(Ref, PeerHost, PeerPort) -> NewRef</name>
-      <name>new_out_connection(Ref, PeerHost, PeerPort, SocketHost, SocketPort) -> NewRef</name>
-      <fsummary>Invoke when setting up a new connection to a server side  ORB</fsummary>
-      <type>
-        <v>Ref    = term() | undefined</v>
-        <v>PeerHost = SocketHost = string(), e.g., "myHost@myServer" or "192.0.0.10"</v>
-        <v>PeerPort = SocketPort = integer()</v>
-        <v>NewRef = term() | {'EXIT', Reason}</v>
-      </type>
-      <desc>
-        <p>When a new connection is set up this function is invoked. Behaves
-          just like <c>new_in_connection</c>; the only difference is that
-          the PeerHost and PeerPort variables identifies the target ORB's bootstrap
-          data and SocketHost and SocketPort are the local interface and port
-          the client ORB connected via.</p>
-      </desc>
-    </func>
-    <func>
-      <name>closed_in_connection(Ref) -> NewRef</name>
-      <fsummary>Invoke when an existing connection to a client side ORB have been terminated</fsummary>
-      <type>
-        <v>Ref    = term()</v>
-        <v>NewRef = term()</v>
-      </type>
-      <desc>
-        <p>When an existing connection is terminated this operation is invoked.
-          The main purpose of this function is to make it possible for a user
-          to clean up all data associated with the associated connection.</p>
-        <p>The input parameter <c>Ref</c> is the return value from 
-          <c>new_in_connection/3</c>.</p>
-      </desc>
-    </func>
-    <func>
-      <name>closed_out_connection(Ref) -> NewRef</name>
-      <fsummary>Invoke when an existing connection to a server side ORB have been terminated</fsummary>
-      <type>
-        <v>Ref    = term()</v>
-        <v>NewRef = term()</v>
-      </type>
-      <desc>
-        <p>When an existing connection is terminated this operation is invoked.
-          The main purpose of this function is to make it possible for a user
-          to clean up all data associated with the associated connection.</p>
-        <p>The input parameter <c>Ref</c> is the return value from 
-          <c>new_out_connection/3</c>.</p>
-      </desc>
-    </func>
-    <func>
-      <name>in_reply(Ref, Obj, Ctx, Op, Data, Extra) -> Reply</name>
-      <fsummary>Invoke when replies arrives at the client side ORB</fsummary>
-      <type>
-        <v>Ref   = term()</v>
-        <v>Obj   = #objref</v>
-        <v>Ctx   = [#'IOP_ServiceContext'{}]</v>
-        <v>Op    = atom()</v>
-        <v>Data  = [Result, OutParameter1, ..., OutPramaterN]</v>
-        <v>Reply = {NewData, NewExtra}</v>
-      </type>
-      <desc>
-        <p>When replies are delivered from the server side ORB to the client side
-          ORB this operation is invoked. The <c>Data</c> parameter is a list in which
-          the first element is the return value value from the target object and
-          the rest is a all parameters defined as <c>out</c> or <c>inout</c> in
-          the IDL-specification.</p>
-      </desc>
-    </func>
-    <func>
-      <name>in_reply_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply</name>
-      <fsummary>Invoke when replies arrives at the client side ORB with undecoded reply body</fsummary>
-      <type>
-        <v>Ref   = term()</v>
-        <v>Obj   = #objref</v>
-        <v>Ctx   = [#'IOP_ServiceContext'{}]</v>
-        <v>Op    = atom()</v>
-        <v>Bin   = #binary</v>
-        <v>Reply = {NewBin, NewExtra}</v>
-      </type>
-      <desc>
-        <p>When replies are delivered from the server side ORB to the client side
-          ORB this operation is invoked. The <c>Bin</c> parameter is the reply 
-          body still uncoded.</p>
-      </desc>
-    </func>
-    <func>
-      <name>in_request(Ref, Obj, Ctx, Op, Args, Extra) -> Reply</name>
-      <fsummary>Invoke when requests arrive at the server side ORB</fsummary>
-      <type>
-        <v>Ref   = term()</v>
-        <v>Obj   = #objref</v>
-        <v>Ctx   = [#'IOP_ServiceContext'{}]</v>
-        <v>Op    = atom()</v>
-        <v>Args  = [Argument] - defined in the IDL-specification</v>
-        <v>Reply = {NewArgs, NewExtra}</v>
-      </type>
-      <desc>
-        <p>When a new request arrives at the server side ORB this operation is 
-          invoked.</p>
-      </desc>
-    </func>
-    <func>
-      <name>in_request_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply</name>
-      <fsummary>Invoke when requests arrive at the server side ORB with undecoded request body</fsummary>
-      <type>
-        <v>Ref   = term()</v>
-        <v>Obj   = #objref</v>
-        <v>Ctx   = [#'IOP_ServiceContext'{}]</v>
-        <v>Op    = atom()</v>
-        <v>Bin   = #binary</v>
-        <v>Reply = {NewBin, NewExtra}</v>
-      </type>
-      <desc>
-        <p>When a new request arrives at the server side ORB this operation is 
-          invoked before decoding the request body.</p>
-      </desc>
-    </func>
-    <func>
-      <name>out_reply(Ref, Obj, Ctx, Op, Data, Extra) -> Reply</name>
-      <fsummary>Invoke after the target object replied</fsummary>
-      <type>
-        <v>Ref   = term()</v>
-        <v>Obj   = #objref</v>
-        <v>Ctx   = [#'IOP_ServiceContext'{}]</v>
-        <v>Op    = atom()</v>
-        <v>Data  = [Result, OutParameter1, ..., OutPramaterN]</v>
-        <v>Reply = {NewData, NewExtra}</v>
-      </type>
-      <desc>
-        <p>After the target object have been invoked this operation is invoked
-          with the result. The <c>Data</c> parameter is a list in which
-          the first element is the return value value from the target object and
-          the rest is a all parameters defined as <c>out</c> or <c>inout</c> in
-          the IDL-specification.</p>
-      </desc>
-    </func>
-    <func>
-      <name>out_reply_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply</name>
-      <fsummary>Invoke after the target object replied with the reply  encoded</fsummary>
-      <type>
-        <v>Ref   = term()</v>
-        <v>Obj   = #objref</v>
-        <v>Ctx   = [#'IOP_ServiceContext'{}]</v>
-        <v>Op    = atom()</v>
-        <v>Bin   = #binary</v>
-        <v>Reply = {NewBin, NewExtra}</v>
-      </type>
-      <desc>
-        <p>This operation is similar to <c>out_reply</c>; the only difference is
-          that the reply body have been encoded.</p>
-      </desc>
-    </func>
-    <func>
-      <name>out_request(Ref, Obj, Ctx, Op, Args, Extra) -> Reply</name>
-      <fsummary>Invoke on the client side ORB before encoding and sending the request</fsummary>
-      <type>
-        <v>Ref   = term()</v>
-        <v>Obj   = #objref</v>
-        <v>Ctx   = [#'IOP_ServiceContext'{}]</v>
-        <v>Op    = atom()</v>
-        <v>Args  = [Argument] - defined in the IDL-specification</v>
-        <v>Reply = {NewArgs, NewExtra}</v>
-      </type>
-      <desc>
-        <p>Before a request is sent to the server side ORB, <c>out_request</c> is
-          invoked.</p>
-      </desc>
-    </func>
-    <func>
-      <name>out_request_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply</name>
-      <fsummary>Invoke on the client side ORB before sending the request</fsummary>
-      <type>
-        <v>Ref   = term()</v>
-        <v>Obj   = #objref</v>
-        <v>Ctx   = [#'IOP_ServiceContext'{}]</v>
-        <v>Op    = atom()</v>
-        <v>Bin   = #binary</v>
-        <v>Reply = {NewBin, NewExtra}</v>
-      </type>
-      <desc>
-        <p>This operation is similar to <c>out_request</c>; the only
-          difference is that the request body have been encoded.</p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/intro_part.xml b/lib/orber/doc/src/intro_part.xml
deleted file mode 100644
index 7e5520e42e..0000000000
--- a/lib/orber/doc/src/intro_part.xml
+++ /dev/null
@@ -1,41 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE part SYSTEM "part.dtd">
-
-<part>
-  <header>
-    <copyright>
-      <year>2002</year>
-      <year>2016</year>
-      <holder>Ericsson AB, All Rights Reserved</holder>
-    </copyright>
-    <legalnotice>
-  Licensed under the Apache License, Version 2.0 (the "License");
-  you may not use this file except in compliance with the License.
-  You may obtain a copy of the License at
- 
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
-
-  The Initial Developer of the Original Code is Ericsson AB.
-    </legalnotice>
-
-    <title>Introduction to Orber and the IFR</title>
-    <prepared>Niclas Eklund</prepared>
-    <docno></docno>
-    <date>2002-06-25</date>
-    <rev>A</rev>
-  </header>
-  <description>
-    <p>This chapter contains an introduction to Orber and the IFR 
-      (Interface Repository).</p>
-  </description>
-  <include file="ch_introduction"></include>
-  <include file="ch_orber_kernel"></include>
-  <include file="ch_ifr"></include>
-</part>
-
diff --git a/lib/orber/doc/src/lname.xml b/lib/orber/doc/src/lname.xml
deleted file mode 100644
index c0c9be1a85..0000000000
--- a/lib/orber/doc/src/lname.xml
+++ /dev/null
@@ -1,166 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>1997</year><year>2017</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>lname</title>
-    <prepared></prepared>
-    <responsible></responsible>
-    <docno></docno>
-    <approved></approved>
-    <checked></checked>
-    <date>1997-06-10</date>
-    <rev>A</rev>
-  </header>
-  <module>lname</module>
-  <modulesummary>Interface that supports the name pseudo-objects.</modulesummary>
-  <description>
-    <p>This interface is a part of the names library which is used to hide the 
-      representation of names. In Orbers Erlang mapping the pseudo-object names 
-      and the real IDL names have the same representation but it is desirable that 
-      the clients uses the names library so they will not be dependent of the representation.
-      The lname interface supports handling of names e.g. adding and removing name 
-      components.</p>
-    <p>Note that the lname interface in orber does not contain a destroy function because 
-      the Names are represented as standard Erlang lists and therefor will be removed 
-      by the garbage collector when not in use.</p>
-    <p>The type <c>NameComponent</c> used below is defined as:</p>
-    <code type="erl">
--record('CosNaming_NameComponent', {id, kind=""}).
-    </code>
-    <p><c>id</c> and <c>kind</c> are strings. </p>
-    <p>The record is defined in the file <c>CosNaming.hrl</c> and it 
-      is included with:</p>
-    <code type="erl">
--include_lib("orber/COSS/CosNaming/CosNaming.hrl").
-    </code>
-  </description>
-  <funcs>
-    <func>
-      <name>create() -> Return</name>
-      <fsummary>Create a new name</fsummary>
-      <type>
-        <v>Return = [NameComponent]</v>
-      </type>
-      <desc>
-        <p>This function returns a new name.</p>
-      </desc>
-    </func>
-    <func>
-      <name>insert_component(Name, N, NameComponent) -> Return</name>
-      <fsummary>Insert a new name component in a name</fsummary>
-      <type>
-        <v>Name = [NameComponent]</v>
-        <v>N = int()</v>
-        <v>Return = Name</v>
-      </type>
-      <desc>
-        <p>This function returns a name where the new name component has been inserted as 
-          component <c>N</c> in Name.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_component(Name, N) -> Return</name>
-      <fsummary>Get a name component from a name</fsummary>
-      <type>
-        <v>Name = [NameComponent]</v>
-        <v>N = int()</v>
-        <v>Return = NameComponent</v>
-      </type>
-      <desc>
-        <p>This function returns the <c>N:th</c> name component in Name.</p>
-      </desc>
-    </func>
-    <func>
-      <name>delete_component(Name, N) -> Return</name>
-      <fsummary>Delete a name component from a name</fsummary>
-      <type>
-        <v>Name = [NameComponent]</v>
-        <v>N = int()</v>
-        <v>Return = Name</v>
-      </type>
-      <desc>
-        <p>This function deletes the <c>N:th</c> name component from Name and returns 
-          the new name.</p>
-      </desc>
-    </func>
-    <func>
-      <name>num_component(Name) -> Return</name>
-      <fsummary>Count the number of name components in a name</fsummary>
-      <type>
-        <v>Name = [NameComponent]</v>
-        <v>Return = int()</v>
-      </type>
-      <desc>
-        <p>This function returns a the number of name components in Name.</p>
-      </desc>
-    </func>
-    <func>
-      <name>equal(Name1, Name2) -> Return</name>
-      <fsummary>Test if two names are equal</fsummary>
-      <type>
-        <v>Name1 = Name2 = [NameComponent]</v>
-        <v>Return = bool()</v>
-      </type>
-      <desc>
-        <p>This function returns true if the two names are equal and false otherwise.</p>
-      </desc>
-    </func>
-    <func>
-      <name>less_than(Name1, Name2) -> Return</name>
-      <fsummary>Test if one name is lesser than the other</fsummary>
-      <type>
-        <v>Name1 = Name2 = [NameComponent]</v>
-        <v>Return = bool()</v>
-      </type>
-      <desc>
-        <p>This function returns true if Name1 are lesser than Name2 and false otherwise.</p>
-      </desc>
-    </func>
-    <func>
-      <name>to_idl_form(Name) -> Return</name>
-      <fsummary>Transform a pseudo name to an IDL name</fsummary>
-      <type>
-        <v>Name = [NameComponent]</v>
-        <v>Return = Name</v>
-      </type>
-      <desc>
-        <p>This function just checks if Name is a correct IDL name before returning it
-          because the name representation is the same for pseudo and IDL names in orber.</p>
-      </desc>
-    </func>
-    <func>
-      <name>from_idl_form(Name) -> Return</name>
-      <fsummary>Transform an IDL name to a pseudo name</fsummary>
-      <type>
-        <v>Name = [NameComponent]</v>
-        <v>Return = Name</v>
-      </type>
-      <desc>
-        <p>This function just returns the Name because the name representation is the 
-          same for pseudo and IDL names in orber.</p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/lname_component.xml b/lib/orber/doc/src/lname_component.xml
deleted file mode 100644
index 8b8001c0fb..0000000000
--- a/lib/orber/doc/src/lname_component.xml
+++ /dev/null
@@ -1,113 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>1997</year><year>2017</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>lname_component</title>
-    <prepared></prepared>
-    <responsible></responsible>
-    <docno></docno>
-    <approved></approved>
-    <checked></checked>
-    <date>1997-06-10</date>
-    <rev>A</rev>
-  </header>
-  <module>lname_component</module>
-  <modulesummary>Interface that supports the name pseudo-objects.</modulesummary>
-  <description>
-    <p>This interface is a part of the name library, which is used to hide the 
-      representation of names. In Orbers Erlang mapping the pseudo-object names 
-      and the real IDL names have the same representation but it is desirable that 
-      the clients uses the names library so they will not be dependent of the representation.
-      The lname_component interface supports handling of name components e.g. set and get
-      of the struct members.</p>
-    <p>Note that the lname_component interface in orber does not contain a destroy 
-      function because the NameComponents are represented as Erlang records and 
-      therefor will be removed by the garbage collector when not in use.</p>
-    <p>The type <c>NameComponent</c> used below is defined as:</p>
-    <code type="erl">
--record('CosNaming_NameComponent', {id, kind=""}).
-    </code>
-    <p><c>id</c> and <c>kind</c> are strings. </p>
-    <p>The record is defined in the file <c>CosNaming.hrl</c> and it 
-      is included with:</p>
-    <code type="erl">
--include_lib("orber/COSS/CosNaming/CosNaming.hrl").
-    </code>
-  </description>
-  <funcs>
-    <func>
-      <name>create() -> Return</name>
-      <fsummary>Create a new name component</fsummary>
-      <type>
-        <v>Return = NameComponent</v>
-      </type>
-      <desc>
-        <p>This function returns a new name component.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_id(NameComponent) -> Return</name>
-      <fsummary>Get the id field of a name component</fsummary>
-      <type>
-        <v>Return = string()</v>
-      </type>
-      <desc>
-        <p>This function returns the id string of a name component.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_id(NameComponent, Id) -> Return</name>
-      <fsummary>Set the id field of a name component</fsummary>
-      <type>
-        <v>Id = string()</v>
-        <v>Return = NameComponent</v>
-      </type>
-      <desc>
-        <p>This function sets the id string of a name component and returns the component.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_kind(NameComponent) -> Return</name>
-      <fsummary>Get the kind field of a name component</fsummary>
-      <type>
-        <v>Return = string()</v>
-      </type>
-      <desc>
-        <p>This function returns the id string of a name component.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_kind(NameComponent, Kind) -> Return</name>
-      <fsummary>Set the kind field of a name component</fsummary>
-      <type>
-        <v>Kind = string()</v>
-        <v>Return = NameComponent</v>
-      </type>
-      <desc>
-        <p>This function sets the kind string of a name component and returns the component.</p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/menuframe.gif b/lib/orber/doc/src/menuframe.gif
deleted file mode 100644
index 57a437e6b0..0000000000
--- a/lib/orber/doc/src/menuframe.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/name.gif b/lib/orber/doc/src/name.gif
deleted file mode 100644
index d2df460092..0000000000
--- a/lib/orber/doc/src/name.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/notes.xml b/lib/orber/doc/src/notes.xml
deleted file mode 100644
index 35da4f73da..0000000000
--- a/lib/orber/doc/src/notes.xml
+++ /dev/null
@@ -1,860 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE chapter SYSTEM "chapter.dtd">
-
-<chapter>
-  <header>
-    <copyright>
-      <year>1997</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-
-    </legalnotice>
-
-    <title>Orber Release Notes</title>
-    <prepared></prepared>
-    <responsible></responsible>
-    <docno></docno>
-    <approved></approved>
-    <checked></checked>
-    <date>99-02-12</date>
-    <rev>A</rev>
-    <file>notes.xml</file>
-  </header>
-
-  <section><title>Orber 3.8.4</title>
-
-    <section><title>Fixed Bugs and Malfunctions</title>
-      <list>
-        <item>
-	    <p> Removed all old unused files in the documentation.
-	    </p>
-          <p>
-	    Own Id: OTP-14475 Aux Id: ERL-409, PR-1493 </p>
-        </item>
-        <item>
-	    <p> Removed the man warnings by using the code tag
-	    instead of c tag. </p>
-          <p>
-	    Own Id: OTP-14673</p>
-        </item>
-      </list>
-    </section>
-
-</section>
-
-<section><title>Orber 3.8.3</title>
-
-    <section><title>Improvements and New Features</title>
-      <list>
-        <item>
-          <p>
-	    Fix some dialyzer warnings</p>
-          <p>
-	    Own Id: OTP-14006</p>
-        </item>
-      </list>
-    </section>
-
-  </section>
-
-  <section><title>Orber 3.8.2</title>
-
-    <section><title>Improvements and New Features</title>
-      <list>
-        <item>
-          <p>
-	    Internal changes</p>
-          <p>
-	    Own Id: OTP-13551</p>
-        </item>
-      </list>
-    </section>
-
-</section>
-
-<section><title>Orber 3.8.1</title>
-
-    <section><title>Improvements and New Features</title>
-      <list>
-        <item>
-	    <p> Suppress Dialyzer warnings. </p>
-          <p>
-	    Own Id: OTP-12862</p>
-        </item>
-      </list>
-    </section>
-
-</section>
-
-<section><title>Orber 3.8</title>
-
-    <section><title>Improvements and New Features</title>
-      <list>
-        <item>
-	    <p> Remove the usage of erlang:now() from all Corba
-	    applications and use the new rand module instead of
-	    random. </p>
-          <p>
-	    Own Id: OTP-12687</p>
-        </item>
-      </list>
-    </section>
-
-</section>
-
-<section><title>Orber 3.7.1</title>
-
-    <section><title>Fixed Bugs and Malfunctions</title>
-      <list>
-        <item>
-	    <p> Fixed problem with IPv6 addresses in Service Context
-	    when orber is default configured for IPv4. </p>
-          <p>
-	    Own Id: OTP-12193</p>
-        </item>
-      </list>
-    </section>
-
-</section>
-
-<section><title>Orber 3.7</title>
-
-    <section><title>Fixed Bugs and Malfunctions</title>
-      <list>
-        <item>
-	    <p> The following functions have been corrected so they
-	    work properly with IPv6 addresses. </p> <list>
-	    <item><c>corba:resolve_initial_references_remote/2/3</c></item>
-	    <item><c>corba:list_initial_references_remote/1/2</c></item>
-	    <item><c>corba:string_to_object/1/2</c></item> </list>
-          <p>
-	    Own Id: OTP-12016</p>
-        </item>
-        <item>
-	    <p> A couple of macros were malformed, missing commas:
-	    PROFILEBODY_1_1_TYPEDEF and PROFILEBODY_1_2_TYPEDEF.
-	    Thanks to Vlad Dumitrescu. </p>
-          <p>
-	    Own Id: OTP-12062</p>
-        </item>
-      </list>
-    </section>
-
-
-    <section><title>Improvements and New Features</title>
-      <list>
-        <item>
-	    <p> It is now possible to add listen interfaces for IPv6
-	    when orber is default configured for IPv4 and the other
-	    way around. For more information, consult the User's
-	    Guide and the orber module Reference Manual. </p>
-          <p>
-	    Own Id: OTP-12007</p>
-        </item>
-      </list>
-    </section>
-
-</section>
-
-<section><title>Orber 3.6.27</title>
-
-    <section><title>Fixed Bugs and Malfunctions</title>
-      <list>
-        <item>
-          <p>
-	    Some local implementations of removing the last element
-	    from a list are replaced by <c>lists:droplast/1</c>. Note
-	    that this requires at least <c>stdlib-2.0</c>, which is
-	    the stdlib version delivered in OTP 17.0. (Thanks to Hans
-	    Svensson)</p>
-          <p>
-	    Own Id: OTP-11678</p>
-        </item>
-      </list>
-    </section>
-
-</section>
-
-<section><title>Orber 3.6.26.1</title>
-
-    <section><title>Improvements and New Features</title>
-      <list>
-        <item>
-	    <p> Postscript files no longer needed for the generation
-	    of PDF files have been removed. </p>
-          <p>
-	    Own Id: OTP-11016</p>
-        </item>
-      </list>
-    </section>
-
-</section>
-
-<section><title>Orber 3.6.26</title>
-
-    <section><title>Fixed Bugs and Malfunctions</title>
-      <list>
-        <item>
-          <p>
-	    Fix bug in corbaloc/corbaname over ssl.</p>
-          <p>
-	    Own Id: OTP-10675</p>
-        </item>
-      </list>
-    </section>
-
-  </section>
-
-  <section><title>Orber 3.6.25</title>
-
-    <section><title>Improvements and New Features</title>
-      <list>
-        <item>
-	    <p> Some examples overflowing the width of PDF pages have
-	    been corrected. </p>
-          <p>
-	    Own Id: OTP-10665</p>
-        </item>
-      </list>
-    </section>
-
-    <section><title>Known Bugs and Problems</title>
-      <list>
-        <item>
-          <p>
-	    Own Id: OTP-10675 Aux Id: seq12154
-	  </p>
-        </item>
-      </list>
-    </section>
-</section>
-
-<section><title>Orber 3.6.24</title>
-
-    <section><title>Fixed Bugs and Malfunctions</title>
-      <list>
-        <item>
-          <p>
-	    Fix number of arguments in orber dbg printout</p>
-          <p>
-	    Own Id: OTP-9887</p>
-        </item>
-        <item>
-	    <p> The descriptions of <c>ssl_server_options</c> and
-	    <c>ssl_client_options</c> are corrected.<br/> Seq. Id:
-	    seq12018 </p>
-          <p>
-	    Own Id: OTP-9966 Aux Id: OTP-9773 </p>
-        </item>
-      </list>
-    </section>
-
-</section>
-
-<section><title>Orber 3.6.23</title>
-
-    <section><title>Fixed Bugs and Malfunctions</title>
-      <list>
-        <item>
-	    <p> Remove usage of ssl:seed/1 in orber test cases. </p>
-          <p>
-	    Own Id: OTP-9728</p>
-        </item>
-      </list>
-    </section>
-
-
-    <section><title>Improvements and New Features</title>
-      <list>
-        <item>
-	    <p>Erlang/OTP can now be built using parallel make if you
-	    limit the number of jobs, for instance using '<c>make
-	    -j6</c>' or '<c>make -j10</c>'. '<c>make -j</c>' does not
-	    work at the moment because of some missing
-	    dependencies.</p>
-          <p>
-	    Own Id: OTP-9451</p>
-        </item>
-        <item>
-	    <p> The SSL option handling has been changed. There are
-	    now two new orber options <c>ssl_server_options</c> and
-	    <c>ssl_client_options</c> which takes a list of options
-	    to the socket. </p> <p> The old options are now
-	    deprecated and removed from the documentation but they
-	    can still be used for backward compatibility as long as
-	    the two new options not are used. </p> <p> If
-	    <c>ssl_server_options</c> and <c>ssl_client_options</c>
-	    contain an TCP option that <c>orber</c> needs to set to a
-	    specific value it will be skipped and a warning will be
-	    written to the error_log. </p>
-          <p>
-	    Own Id: OTP-9773 Aux Id: seq11932 </p>
-        </item>
-      </list>
-    </section>
-
-</section>
-
-<section><title>Orber 3.6.22</title>
-
-    <section><title>Fixed Bugs and Malfunctions</title>
-      <list>
-        <item>
-	    <p> XML files have been corrected. </p>
-          <p>
-	    Own Id: OTP-9550 Aux Id: OTP-9541 </p>
-        </item>
-      </list>
-    </section>
-
-</section>
-
-<section>
-    <title>Orber 3.6.21</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>
-            Eliminated Dialyzer warnings.</p>
-          <p>
-            Own Id: OTP-9326 Aux Id:</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.20</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>
-            Eliminated Dialyzer warnings when using exit or throw.</p>
-          <p>
-            Own Id: OTP-9050 Aux Id:</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.19</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>
-            Partial support for recursive structs and unions.
-            Only available for the erl_corba backend and requires
-            that Light IFR is used. I.e. the IC option {light_ifr, true}
-            and that Orber is configured in such a way that Light IFR
-            is activated. Recursive TypeCode is currently not supported.</p>
-          <p>
-            Own Id: OTP-8868 Aux Id: seq11633</p>
-        </item>
-      </list>
-    </section>
-    <section>
-      <title>Fixed Bugs and Malfunctions</title>
-      <list type="bulleted">
-        <item>
-          <p>The SSL option {ssl_imp, old} was not used if ssl_generation was
-             set to 2. Only R14B was affected by this.</p>
-          <p>Own Id: OTP-8994 Aux Id: seq11747</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.18</title>
-    <section>
-      <title>Fixed Bugs and Malfunctions</title>
-      <list type="bulleted">
-        <item>
-          <p>A corbaloc http string could return an EXIT message, instead
-             of a system exception, if the HTTP server closed the socket
-             without returning a complete message. I.e. header and a body
-             containing a stringified IOR.</p>
-          <p>Own Id: OTP-8900 Aux Id: seq11704</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.17</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>
-            Eliminated warnings for auto-imported BIF clashes.</p>
-          <p>
-            Own Id: OTP-8840</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.16</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>
-            Test suites published.</p>
-          <p>
-            Own Id: OTP-8543O Aux Id:</p>
-        </item>
-      </list>
-    </section>
-
-    <section>
-      <title>Fixed Bugs and Malfunctions</title>
-      <list type="bulleted">
-        <item>
-          <p>Added missing trailing bracket to define in hrl-file.</p>
-          <p>Own Id: OTP-8489 Aux Id:</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.15</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>
-            Added the configuration parameters iiop_out_ports_attempts and
-            iiop_out_ports_random.</p>
-          <p>
-            Own Id: OTP-8448 Aux Id: seq11498</p>
-        </item>
-        <item>
-          <p>
-            Removed obsolete SSL dependency.</p>
-          <p>
-            Own Id: OTP-8374 Aux Id:</p>
-        </item>
-        <item>
-          <p>
-            Removed the usage of the codeinclude tag in the documentation.</p>
-          <p>
-            Own Id: OTP-8409 Aux Id:</p>
-        </item>
-      </list>
-    </section>
-
-    <section>
-      <title>Fixed Bugs and Malfunctions</title>
-      <list type="bulleted">
-        <item>
-          <p>Removed superfluous VT in the documentation.</p>
-          <p>Own Id: OTP-8353 Aux Id:</p>
-        </item>
-        <item>
-          <p>Removed superfluous backslash in the documentation.</p>
-          <p>Own Id: OTP-8354 Aux Id:</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.14</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>
-            The documentation is now built with open source tools (xsltproc and fop) 
-            that exists on most platforms. One visible change is that the frames are removed.</p>
-          <p>
-            Own Id: OTP-8201 Aux Id:</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.13</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>Obsolete guards, e.g. record vs is_record, has been changed 
-             to avoid compiler warnings.</p>
-          <p>Own Id: OTP-7987</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.12</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>Only the source instance of InitialReference.java is now
-             included. Users are adviced to use the Interoperable
-             Naming Service (INS) instead. INS is a part of the OMG
-             standard specification.</p>
-          <p>*** POTENTIAL INCOMPATIBILITY ***</p>
-          <p>Own Id: OTP-7906 Aux Id: seq11243</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.11</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>Updated file headers.</p>
-          <p>Own Id: OTP-7837</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.10</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>Documentation source included in open source releases.</p>
-          <p>Own Id: OTP-7595</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.9</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>Updated file headers.</p>
-          <p>Own Id: OTP-7011</p>
-        </item>
-        <item>
-          <p>Now compliant with the new behavior of stdlib.</p>
-          <p>Own Id: OTP-7030 Aux Id: seq10827</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.8</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>When a local port range has been defined (i.e. iiop_out_ports),
-	     Orber set the socket option reuseaddr to true and after one
-	     timed out connection attempt no other port in the given range
-	     is used for that particular connect attempt.</p>
-          <p>Own Id: OTP-6844 Aux Id: </p>
-        </item>
-        <item>
-          <p>Possible to override global SSL parameters when using
-             local interfaces.</p>
-          <p>Own Id: OTP-6869 Aux Id: seq10742</p>
-        </item>
-      </list>
-    </section>
-    <section>
-      <title>Fixed Bugs and Malfunctions</title>
-      <list type="bulleted">
-        <item>
-          <p>The parameter ssl_client_ciphers was used on the server side as well
-             instead of ssl_server_ciphers.</p>
-          <p>Own Id: OTP-6868 Aux Id:</p>
-        </item>
-        <item>
-          <p>The configuration parameter iiop_max_in_requests was ignored, until
-             the first incoming request arrived, if iiop_packet_size was set.</p>
-          <p>Own Id: OTP-6912 Aux Id:</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.7</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>The documentation source has been converted from SGML to XML.</p>
-          <p>Own Id: OTP-6754 Aux Id: </p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.6</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>It is now possible to configure incoming connections which
-            overrides some global configuration parameters. See
-            orber:add_listen_interface/2/3.</p>
-          <p>Own Id: OTP-6696 Aux Id: </p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.5</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>Removed some unused code.</p>
-          <p>Own Id: OTP-6527 Aux Id: </p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.4</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>Orber can now be configured so that different NAT parameters
-            can be specified for different interfaces.</p>
-          <p>Own Id: OTP-6165 Aux Id: </p>
-        </item>
-        <item>
-          <p>It is now possible to set the keepalive option for incoming
-            and outgoing IIOP connections. For more information, see the
-            Configuration chapter in the User's Guide.</p>
-          <p>Own Id: OTP-6370 Aux Id: seq10532</p>
-        </item>
-        <item>
-          <p>The new function orber:close_connection/1/2 allows a client
-            to close connections to an object residing on a remote ORB.</p>
-          <p>Own Id: OTP-6371 Aux Id: seq10532</p>
-        </item>
-        <item>
-          <p>Orber now use the SSL two-phase accept strategy to avoid
-            that new incoming connections via SSL are not blocked
-            by a previous connect attempt that never initiated the
-            SSL handshake. Note, the configuration parameter
-            iiop_ssl_accept_timeout should be set (default infinity).
-            For more information, see the Configuration chapter in the
-            User's Guide. If Orber is started in secure mode, the
-            installed SSL version must support ssl:ssl_accept/1/2 and
-            ssl:transport_accept/1/2.</p>
-          <p>Own Id: OTP-6372 Aux Id: seq10105</p>
-        </item>
-      </list>
-    </section>
-
-    <section>
-      <title>Fixed Bugs and Malfunctions</title>
-      <list type="bulleted">
-        <item>
-          <p>The operation orber_ifr:contents/2 could only handle dk_All.</p>
-          <p>Own Id: OTP-6385 Aux Id:</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.3</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>When installing Orber it is now possible to set the priority
-            for Orber internal Mnesia tables. For more information, see the
-            Reference Manual regarding orber:install/2.</p>
-          <p>Own Id: OTP-5907 Aux Id: seq10156</p>
-        </item>
-        <item>
-          <p>The operation corba_object:is_a/2/3 now only connect to a remote
-            ORB if necessary (i.e. the target object inherits from objects
-            associated with the given IFR id).</p>
-          <p>Own Id: OTP-5908</p>
-        </item>
-      </list>
-    </section>
-
-    <section>
-      <title>Fixed Bugs and Malfunctions</title>
-      <list type="bulleted">
-        <item>
-          <p>The operation corba_object:is_remote/1 always returned
-            true, which was introduced in orber-3.2.10.</p>
-          <p>Own Id: OTP-5909</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.2</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>Native interceptors may now export new_in_connection and 
-            new_out_connection operations with arity 5. If this is the
-            case, information about the local interface and port is
-            passed to the interceptor. Orber's built in interceptors
-            have been changed to include this information as well.</p>
-          <p>Own Id: OTP-5671</p>
-        </item>
-      </list>
-    </section>
-
-    <section>
-      <title>Fixed Bugs and Malfunctions</title>
-      <list type="bulleted">
-        <item>
-          <p>In some cases, e.g. incorrect GIOP headers or a CancelRequest
-            containing a non-existing RequestId, the incoming connection 
-            would be terminated.</p>
-          <p>Own Id: OTP-5672 Aux Id: seq10037</p>
-        </item>
-        <item>
-          <p>If combining the 'Use Current Interface in IOR' and
-            'Use IPv6' flags, exported IOR:s contained an incorrect
-            host address.</p>
-          <p>Own Id: OTP-5673</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6.1</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>Reduced overhead when using outgoing ACL with a local interface
-            defined.</p>
-          <p>Own Id: OTP-5659</p>
-        </item>
-        <item>
-          <p>Added guards to ensure that, when so required, a list
-            of IOP_ServiceContext's is passed instead of, for example,
-            just the context record.</p>
-          <p>Own Id: OTP-5660</p>
-        </item>
-      </list>
-    </section>
-
-    <section>
-      <title>Fixed Bugs and Malfunctions</title>
-      <list type="bulleted">
-        <item>
-          <p>The documentation referred to two different context definitions,
-            the incorrect ServiceContext and the correct IOP_ServiceContext.
-            The hrl file PATH/include/corba.hrl also contained the incorrect
-            record definition. This has now been updated so that only
-            IOP_ServiceContext is used and referred to.</p>
-          <p>Own Id: OTP-5658</p>
-        </item>
-      </list>
-    </section>
-  </section>
-
-  <section>
-    <title>Orber 3.6</title>
-
-    <section>
-      <title>Improvements and New Features</title>
-      <list type="bulleted">
-        <item>
-          <p>It is now possible to define a Access Control List (ACL),
-            which limits the host and ports Orber may connect to or
-            accept connections from.</p>
-          <p>Own Id: OTP-5567</p>
-        </item>
-        <item>
-          <p>It is now possible to add, and remove, listen interfaces.
-            For more information, consult the User's Guide and the 
-            orber module Reference Manual.</p>
-          <p>Own Id: OTP-5568</p>
-        </item>
-        <item>
-          <p>It is now possible to activate and deactivate Audit/Trail
-            logging. One of the three built in interceptors will be used
-            depending on the requested verbosity.</p>
-          <p>Own Id: OTP-5569</p>
-        </item>
-        <item>
-          <p>It is now possible to configure Orber to add the interface,
-            to exported local IOR:s, a Request came via.</p>
-          <p>Own Id: OTP-5570</p>
-        </item>
-        <item>
-          <p>It is now possible to instruct Orber which local interface an outgoing Request
-            shall be sent via. To accomplish this the Orber generic context must be
-            added added to each invocation.</p>
-          <p>Own Id: OTP-5571</p>
-        </item>
-        <item>
-          <p>It is now possible to define a default local interface,
-            which Orber will use when connecting to another ORB.</p>
-          <p>Own Id: OTP-5583</p>
-        </item>
-      </list>
-    </section>
-  </section>
-</chapter>
-
diff --git a/lib/orber/doc/src/orber.xml b/lib/orber/doc/src/orber.xml
deleted file mode 100644
index d8c6936515..0000000000
--- a/lib/orber/doc/src/orber.xml
+++ /dev/null
@@ -1,653 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>1997</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-
-    </legalnotice>
-
-    <title>orber</title>
-    <prepared></prepared>
-    <responsible></responsible>
-    <docno></docno>
-    <approved></approved>
-    <checked></checked>
-    <date>1997-06-10</date>
-    <rev>A</rev>
-  </header>
-  <module>orber</module>
-  <modulesummary>The main module of the Orber application</modulesummary>
-  <description>
-    <p>This module contains the functions for starting and stopping the 
-      application. It also has some utility functions to get some of 
-      the configuration information from running application.</p>
-  </description>
-  <funcs>
-    <func>
-      <name>start() -> ok</name>
-      <name>start(Type) -> ok</name>
-      <fsummary>Start the Orber application</fsummary>
-      <type>
-        <v>Type = temporary | permanent</v>
-      </type>
-      <desc>
-        <p>Starts the Orber application (it also starts mnesia if it is not running).
-          Which <c>Type</c> parameter is supplied determines the behavior. If not
-          supplied Orber is started as <c>temporary</c>. 
-          See the Reference Manual <em>application(3)</em> for further information. </p>
-      </desc>
-    </func>
-    <func>
-      <name>jump_start(Attributes) -> ok | {'EXIT', Reason}</name>
-      <fsummary>Start the Orber application during tests</fsummary>
-      <type>
-        <v>Attributes = Port | Options</v>
-        <v>Port = integer()</v>
-        <v>Options = [{Key, Value}]</v>
-        <v>Key = any key listed in the configuration chapter</v>
-        <v>Value = allowed value associated with the given key</v>
-      </type>
-      <desc>
-        <p>Installs and starts the Orber and the Mnesia applications with the configuration
-          parameters <c>domain</c> and <c>iiop_port</c> set to <c>"IP-number:Port"</c>
-          and the supplied Port respectively. Theses settings are in most cases
-          sufficient to ensure that no clash with any other Orber instance occur.
-          If this operation fails, check if the listen port (iiop_port) is already
-          in use. This function <em>MAY ONLY</em> be used during development and
-          tests; how Orber is configured when using this operation may change 
-          at any time without warning.</p>
-      </desc>
-    </func>
-    <func>
-      <name>stop() -> ok</name>
-      <fsummary>Stop the Orber application</fsummary>
-      <desc>
-        <p>Stops the Orber application.</p>
-      </desc>
-    </func>
-    <func>
-      <name>info() -> ok</name>
-      <name>info(IoType) -> ok | {'EXIT', Reason} | string()</name>
-      <fsummary>Generate Info Report, which contain Orber's configuration  settings</fsummary>
-      <type>
-        <v>IoType = info_msg | string | io | {io, IoDevice}</v>
-      </type>
-      <desc>
-        <p>Generates an Info Report, which contain Orber's configuration settings.
-          If no <c>IoType</c> is supplied, <c>info_msg</c> is used (see the
-          error_logger documentation). When the atom string is supplied this
-          function will return a flat list. For <c>io</c> and <c>{io, IoDevice}</c>,
-          <c>io:format/1</c> and <c>io:format/3</c> is used respectively.</p>
-      </desc>
-    </func>
-    <func>
-      <name>exception_info(Exception) -> {ok, string()} | {error, Reason}</name>
-      <fsummary>Return a printable string, which describes the supplied  exception</fsummary>
-      <desc>
-        <p>Returns a printable string, which describes the supplied exception
-          in greater detail. Note, this function is mainly intended for
-          system exceptions.</p>
-      </desc>
-    </func>
-    <func>
-      <name>is_system_exception(Exception) -> true | false</name>
-      <fsummary>Return true if the supplied exception is a system defined  exception otherwise false</fsummary>
-      <desc>
-        <p>Returns true if the supplied exception is a system defined 
-          exception, otherwise false.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_tables() -> [Tables]</name>
-      <fsummary>Get the Mnesia tables Orber uses.</fsummary>
-      <desc>
-        <p>Returns a list of the Orber specific Mnesia tables. This list is
-          required to restore Mnesia if it has been partitioned.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_ORBInitRef() -> string() | undefined</name>
-      <fsummary>Get the initial reference address.</fsummary>
-      <desc>
-        <p>This function returns undefined if we will resolve references locally,
-          otherwise a string describing which host we will contact if the Key given
-          to <c>corba:resolve_initial_references/1</c> matches the Key set
-          in this configuration variable. For more information
-          see the user's guide.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_ORBDefaultInitRef() -> string() | undefined</name>
-      <fsummary>Get the initial reference address.</fsummary>
-      <desc>
-        <p>This function returns undefined if we will resolve references locally,
-          otherwise a string describing which host, or hosts, from which we
-          will try to resolve the Key given to 
-          <c>corba:resolve_initial_references/1</c>. For more information
-          see the user's guide.</p>
-      </desc>
-    </func>
-    <func>
-      <name>domain() -> string()</name>
-      <fsummary>Display the Orber domain name</fsummary>
-      <desc>
-        <p>This function returns the domain name of the current Orber domain
-          as a string.</p>
-      </desc>
-    </func>
-    <func>
-      <name>iiop_port() -> int()</name>
-      <fsummary>Display the IIOP port number</fsummary>
-      <desc>
-        <p>This function returns the port-number, which is used by the IIOP
-          protocol. It can be configured by setting the application variable 
-          <em>iiop_port</em>, if it is not set it will have the default number
-          4001.</p>
-      </desc>
-    </func>
-    <func>
-      <name>iiop_out_ports() -> 0 | {Min, Max}</name>
-      <fsummary>Display the ports Orber may use when connecting to another ORB</fsummary>
-      <desc>
-        <p>The return value of this operation is what the configuration
-          parameter <seealso marker="ch_install#config">iiop_out_ports</seealso>
-          has been set to.</p>
-      </desc>
-    </func>
-
-    <func>
-      <name>iiop_out_ports_random() -> true | false</name>
-      <fsummary>Determine if Orber should select local ports randomly</fsummary>
-      <desc>
-        <p>Return the value of the configuration parameter
-           <seealso marker="ch_install#config">iiop_out_ports_random</seealso>.</p>
-      </desc>
-    </func>
-
-    <func>
-      <name>iiop_out_ports_attempts() -> int()</name>
-      <fsummary>Display if Orber should accept more than one timeout connecting to another ORB</fsummary>
-      <desc>
-        <p>Return the value of the configuration parameter
-           <seealso marker="ch_install#config">iiop_out_ports_attempts</seealso>.</p>
-      </desc>
-    </func>
-
-
-    <func>
-      <name>iiop_ssl_port() -> int()</name>
-      <fsummary>Display the IIOP port number used for secure connections</fsummary>
-      <desc>
-        <p>This function returns the port-number, which is used by the secure IIOP
-          protocol. It can be configured by setting the application variable 
-          <em>iiop_ssl_port</em>, if it is not set it will have the default number
-          4002 if Orber is to configured to run in secure mode. Otherwise it returns -1.</p>
-      </desc>
-    </func>
-    <func>
-      <name>iiop_timeout() -> int() (milliseconds)</name>
-      <fsummary>Display the IIOP timeout value</fsummary>
-      <desc>
-        <p>This function returns the timeout value after which outgoing IIOP requests terminate.
-          It can be configured by setting the application variable 
-          <em>iiop_timeout TimeVal (seconds)</em>, if it is not set it will have the default value
-          <em>infinity</em>. If a request times out a system exception, e.g.
-          <em>TIMEOUT</em>, is raised.</p>
-        <p>Note: the iiop_timeout configuration parameter (TimeVal) may only range between 0 and 1000000 seconds. 
-          Otherwise, the default value is used.</p>
-        <p>Note: Earlier IC versions required that the compile option <c>{timeout,"module::interface"}</c>,
-          was used, which allow the user to add an extra timeout parameter, e.g., 
-          <c>module_interface:function(ObjRef, Timeout, ... Arguments ...)</c> or
-          <c>module_interface:function(ObjRef, [{timeout, Timeout}], ... Arguments ...)</c>, 
-          instead of <c>module_interface:function(ObjRef, ... Arguments ...)</c>. 
-          This is no longer the case and if the extra Timeout is used,
-          argument will override the configuration parameter <c>iiop_timeout</c>.
-          It is, however, not possible
-          to use <c>infinity</c> to override the Timeout parameter. The Timeout
-          option is also valid for objects which resides within the same Orber domain.</p>
-      </desc>
-    </func>
-    <func>
-      <name>iiop_connection_timeout() -> int() (milliseconds)</name>
-      <fsummary>Display the IIOP connection timeout value</fsummary>
-      <desc>
-        <p>This function returns the timeout value after which outgoing IIOP connections terminate.
-          It can be configured by setting the application variable 
-          <em>iiop_connection_timeout TimeVal (seconds)</em>, if it is not set it will have the default value
-          <em>infinity</em>. The connection will not be terminated if there are 
-          pending requests.</p>
-        <p>Note: the iiop_connection_timeout configuration parameter (TimeVal) may only range between 0 and 1000000 seconds. 
-          Otherwise, the default value is used.</p>
-      </desc>
-    </func>
-    <func>
-      <name>iiop_connections() -> Result</name>
-      <name>iiop_connections(Direction) -> Result</name>
-      <fsummary>List all existing connections to/from other ORB's</fsummary>
-      <type>
-        <v>Direction = in | out | inout</v>
-        <v>Result = [{Host, Port}] | [{Host, Port, Interface}] | {'EXIT',Reason}</v>
-        <v>Host = string()</v>
-        <v>Port = integer()</v>
-        <v>Interface = string()</v>
-        <v>Reason = term()</v>
-      </type>
-      <desc>
-        <p>The list returned by this operation contain tuples of remote hosts/ports
-          Orber is currently connected to. If no Direction is not supplied, both
-          incoming and outgoing connections are included.</p>
-        <p>If a specific local interface has been defined for the connection,
-          this will be added to the returned tuple.</p>
-      </desc>
-    </func>
-    <func>
-      <name>iiop_connections_pending() -> Result</name>
-      <fsummary>List all connections to another ORB currently being set up</fsummary>
-      <type>
-        <v>Result = [{Host, Port}] | [{Host, Port, Interface}] | {'EXIT',Reason}</v>
-        <v>Host = string()</v>
-        <v>Port = integer()</v>
-        <v>Interface = string()</v>
-        <v>Reason = term()</v>
-      </type>
-      <desc>
-        <p>In some cases a connection attempt (i.e. trying to communicate with
-          another ORB) may block due to a number of reasons. This operation
-          allows the user to check if this is the case. The returned list
-          contain tuples of remote hosts/ports. Normally, the list is empty.</p>
-        <p>If a specific local interface has been defined for the connection,
-          this will be added to the returned tuple.</p>
-      </desc>
-    </func>
-    <func>
-      <name>iiop_in_connection_timeout() -> int() (milliseconds)</name>
-      <fsummary>Display the IIOP connection timeout value for incoming connections</fsummary>
-      <desc>
-        <p>This function returns the timeout value after which incoming IIOP 
-          connections terminate. It can be configured by setting the application 
-          variable <em>iiop_in_connection_timeout TimeVal (seconds)</em>, if it is
-          not set it will have the default value <em>infinity</em>. The connection
-          will not be terminated if there are pending requests.</p>
-        <p>Note: the iiop_in_connection_timeout configuration parameter (TimeVal) may 
-          only range between 0 and 1000000 seconds. Otherwise, the default value is
-          used.</p>
-      </desc>
-    </func>
-    <func>
-      <name>iiop_acl() -> Result</name>
-      <fsummary>Return the ACL configuration</fsummary>
-      <type>
-        <v>Result = [{Direction, Filter}] | [{Direction, Filter, [Interface]}]</v>
-        <v>Direction = tcp_in | ssl_in | tcp_out | ssl_out</v>
-        <v>Filter = string()</v>
-        <v>Interface = string()</v>
-      </type>
-      <desc>
-        <p>Returns the ACL configuration. The <c>Filter</c> uses a extended format of 
-          Classless Inter Domain Routing (CIDR). For example, <c>"123.123.123.10"</c> limits
-          the connection to that particular host, while <c>"123.123.123.10/17"</c> allows
-          connections to or from any host equal to the 17 most significant bits. Orber
-          also allow the user to specify a certain port or port range, for example,
-          <c>"123.123.123.10/17#4001"</c> and <c>"123.123.123.10/17#4001/5001"</c>
-          respectively. IPv4 or none compressed IPv6 strings are accepted.          <br></br>
-
-          The list of <c>Interfaces</c>, IPv4 or IPv6 strings, are currently only used
-          for outgoing connections and may only contain <em>one</em> address. If set and
-          access is granted, Orber will use that local interface when connecting to the
-          other ORB. The module <seealso marker="orber_acl">orber_acl</seealso>
-          provides operations for evaluating the access control for filters and addresses.</p>
-      </desc>
-    </func>
-    <func>
-      <name>activate_audit_trail() -> Result</name>
-      <name>activate_audit_trail(Verbosity) -> Result</name>
-      <fsummary>Activate IIOP audit/trail</fsummary>
-      <type>
-        <v>Verbosity = stealth | normal | verbose</v>
-        <v>Result = ok | {error, Reason}</v>
-        <v>Reason = string()</v>
-      </type>
-      <desc>
-        <p>Activates audit/trail for all existing incoming and outgoing IIOP
-          connections. The <c>Verbosity</c> parameter, <c>stealth</c>, 
-          <c>normal</c> or <c>verbose</c>, determines which of the built in
-          interceptors is used (<c>orber_iiop_tracer_stealth</c>, 
-          <c>orber_iiop_tracer_silent</c> or <c>orber_iiop_tracer</c> respectively).
-          If no verbosity level is supplied, then the <c>normal</c> will be used.</p>
-        <p>In case Orber is configured to use other interceptors, the audit/trail
-          interceptors will simply be added to that list.</p>
-      </desc>
-    </func>
-    <func>
-      <name>deactivate_audit_trail() -> Result</name>
-      <fsummary>Deactivate IIOP audit/trail</fsummary>
-      <type>
-        <v>Result = ok | {error, Reason}</v>
-        <v>Reason = string()</v>
-      </type>
-      <desc>
-        <p>Deactivates audit/trail for all existing incoming and outgoing IIOP
-          connections. In case Orber is configured to use other interceptors, 
-          those will still be used.</p>
-      </desc>
-    </func>
-    <func>
-      <name>add_listen_interface(IP, Type) -> Result</name>
-      <name>add_listen_interface(IP, Type, Port) -> Result</name>
-      <name>add_listen_interface(IP, Type, ConfigurationParameters) -> Result</name>
-      <fsummary>Add a new listen process for incoming connection</fsummary>
-      <type>
-        <v>IP = string</v>
-        <v>Type = normal | ssl</v>
-        <v>Port = integer() > 0</v>
-        <v>ConfigurationParameters = [{Key, Value}]</v>
-        <v>Key = flags | ip_family | iiop_in_connection_timeout | iiop_max_fragments | iiop_max_in_requests | interceptors | iiop_port | iiop_ssl_port | ssl_server_options</v>
-        <v>Value = as described in the User's Guide or below</v>
-        <v>Result = {ok, Ref} | {error, Reason} | {'EXCEPTION', #'BAD_PARAM'{}}</v>
-        <v>Ref = #Ref</v>
-        <v>Reason = string()</v>
-      </type>
-      <desc>
-        <p>Create a new process that handle requests for creating a new incoming
-          IIOP connection via the given interface and port. If the latter is 
-          excluded, Orber will use the value of the <c>iiop_port</c> or 
-          <c>iiop_ssl_port</c> configuration parameters.
-          The <c>Type</c> parameter determines if it is
-          supposed to be IIOP or IIOP via SSL. If successful, the returned
-          <c>#Ref</c> shall be passed to <c>orber:remove_listen_interface/1</c>
-          when the connection shall be terminated.</p>
-        <p>It is also possible to supply configuration parameters that override
-          the global configuration. The <em>iiop_in_connection_timeout</em>,
-          <em>iiop_max_fragments</em>, <em>iiop_max_in_requests</em> and
-          <em>interceptors</em> parameters simply overrides the global
-          counterparts (See the
-          <seealso marker="ch_install#config">Configuration</seealso> chapter
-          in the User's Guide). 
-          But for the following parameters there are a few restrictions:</p>
-        <list type="bulleted">
-          <item><em>flags</em> - currently it is only possible to override the global
-           setting for the <c>Use Current Interface in IOR</c> and 
-          <c>Exclude CodeSet Component</c> flags.</item>
-	  <item><em>ip_family</em> - can be set to <c>inet</c> or <c>inet6</c> and is 
-	  used to get a listen interface that uses another IP version than the default
-	  set with flags at startup.</item>
-          <item><em>iiop_port</em> - requires that <c>Use Current Interface in IOR</c>
-           is activated and the supplied <c>Type</c> is <c>normal</c>. If so,
-           exported IOR:s will contain the IIOP port defined by this configuration
-           parameter. Otherwise, the global setting will be used.</item>
-          <item><em>iiop_ssl_port</em> - almost equivalent to <c>iiop_port</c>.
-           The difference is that <c>Type</c> shall be <c>ssl</c> and that
-           exported IOR:s will contain the IIOP via SSL port defined by this configuration
-           parameter.</item>	
-        </list>
-        <p>If it is not possible to add a listener based on the supplied interface
-          and port, the error message is one of the ones described in <c>inet</c>
-          and/or <c>ssl</c> documentation.</p>
-      </desc>
-    </func>
-    <func>
-      <name>remove_listen_interface(Ref) -> ok</name>
-      <fsummary>Terminate listen process for incoming connection</fsummary>
-      <type>
-        <v>Ref = #Ref</v>
-      </type>
-      <desc>
-        <p>Terminates the listen process, associated with the supplied <c>#Ref</c>,
-          for incoming a connection. The Ref parameter is the return value from
-          the <c>orber:add_listen_interface/2/3</c> operation. When terminating
-          the connection, all associated requests will not deliver a reply to
-          the clients.</p>
-      </desc>
-    </func>
-    <func>
-      <name>close_connection(Connection) -> Result</name>
-      <name>close_connection(Connection, Interface) -> Result</name>
-      <fsummary>Terminate outgoing connection(s)</fsummary>
-      <type>
-        <v>Connection = Object | [{Host, Port}]</v>
-        <v>Object = #objref (external)</v>
-        <v>Host = string()</v>
-        <v>Port = string()</v>
-        <v>Interface = string()</v>
-        <v>Result = ok | {'EXCEPTION', #'BAD_PARAM'{}}</v>
-      </type>
-      <desc>
-        <p>Will try to close all outgoing connections to the host/port combinations
-          found in the supplied object reference or the given list of hosts/ports.
-          If a <c>#'IOP_ServiceContext'{}</c> containing a local interface has been
-          used when communicating with the remote object
-          (see also <seealso marker="Module_Interface">Module_Interface</seealso>), 
-          that interface shall be passed as the second argument. Otherwise, connections
-          via the default local interface, will be terminated.</p>
-        <p></p>
-        <note>
-          <p>Since several clients maybe communicates via the same connection,
-            they will be affected when invoking this operation. Other clients may
-            re-create the connection by invoking an operation on the target object.</p>
-        </note>
-      </desc>
-    </func>
-    <func>
-      <name>secure() -> no | ssl</name>
-      <fsummary>Display the security mode Orber is running in</fsummary>
-      <desc>
-        <p>This function returns the security mode Orber is running in, which is either no if it is an 
-          insecure domain or the type of security mechanism used. For the moment the only security 
-          mechanism is ssl. This is configured by setting the application variable 
-          <em>secure</em>.</p>
-      </desc>
-    </func>
-    <func>
-      <name>ssl_server_options() -> list()</name>
-      <fsummary>Display the SSL server options</fsummary>
-      <desc>
-        <p>This function returns the list of SSL options set for the Orber domain as server. 
-          This is configured by setting the application variable 
-          <em>ssl_server_options</em>.</p>
-      </desc>
-    </func>
-    <func>
-      <name>ssl_client_options() -> list()</name>
-      <fsummary>Display the SSL client options</fsummary>
-      <desc>
-        <p>This function returns the list of SSL options used in outgoing calls in the current process.
-          The default value is configured by setting the application variable 
-          <em>ssl_client_options</em>.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_ssl_client_options(Options) -> ok</name>
-      <fsummary>Set the SSL options for the client</fsummary>
-      <type>
-        <v>Options = list()</v>
-      </type>
-      <desc>
-        <p>This function takes a list of SSL options as parameter and sets 
-	it for the current process.</p>
-      </desc>
-    </func>
-    <func>
-      <name>objectkeys_gc_time() -> int() (seconds)</name>
-      <fsummary>Display the Object Keys GC time value</fsummary>
-      <desc>
-        <p>This function returns the timeout value after which after which terminated object keys, 
-          related to servers started with the configuration parameter <c>{persistent, true}</c>,
-          will be removed.
-          It can be configured by setting the application variable <em>objectkeys_gc_time TimeVal (seconds)</em>, 
-          if it is not set it will have the default value <em>infinity</em>. </p>
-        <p>Objects terminating with reason <em>normal</em> or <em>shutdown</em> are removed automatically.</p>
-        <p>Note: the objectkeys_gc_time configuration parameter (TimeVal) may only range between 0 and 1000000 seconds. 
-          Otherwise, the default value is used.</p>
-      </desc>
-    </func>
-    <func>
-      <name>orber_nodes() -> RetVal</name>
-      <fsummary>Displays which nodes that this orber domain consist of.</fsummary>
-      <type>
-        <v>RetVal = [node()]</v>
-      </type>
-      <desc>
-        <p>This function returns the list of node names that this orber 
-          domain consists of. </p>
-      </desc>
-    </func>
-    <func>
-      <name>install(NodeList) -> ok</name>
-      <name>install(NodeList, Options) -> ok</name>
-      <fsummary>Install the Orber application</fsummary>
-      <type>
-        <v>NodeList = [node()]</v>
-        <v>Options = [Option]</v>
-        <v>Option = {install_timeout, Timeout} | {ifr_storage_type, TableType} | {nameservice_storage_type, TableType} | {initialreferences_storage_type, TableType} | {load_order, Priority}</v>
-        <v>Timeout = infinity | integer()</v>
-        <v>TableType = disc_copies | ram_copies</v>
-        <v>Priority = integer()</v>
-      </type>
-      <desc>
-        <p>This function installs all the necessary mnesia tables and
-          load default data in some of them. If one or more Orber tables
-          already exists the installation fails. The function
-          <em>uninstall</em> may be used, if it is safe, i.e., no other 
-          application is running Orber.</p>
-        <p>Preconditions:</p>
-        <list type="bulleted">
-          <item>a mnesia schema must exist before the installation</item>
-          <item>mnesia is running on the other nodes if the new installation 
-           shall be a multi node domain</item>
-        </list>
-        <p>Mnesia will be started by the function if it is not already running on 
-          the installation node and if it was started it will be stopped
-          afterwards.</p>
-        <p>The options that can be sent to the installation program is:</p>
-        <list type="bulleted">
-          <item><c>{install_timeout, Timeout}</c> - this timeout is how long we 
-           will wait for the tables to be created. The Timeout value can be
-          <em>infinity</em> or an integer number in milliseconds.
-           Default is infinity.</item>
-          <item><c>{ifr_storage_type, TableType}</c> - this option sets the 
-           type of tables used for the interface repository.
-           The TableType can be disc_copies or ram_copies. Default is 
-           disc_copies.</item>
-          <item><c>{initialreferences_storage_type, TableType}</c> - this option 
-           sets the type of table used for storing initial references.
-           The TableType can be disc_copies or ram_copies. Default is 
-           ram_copies.</item>
-          <item><c>{nameservice_storage_type, TableType}</c> - the default
-           behavior of Orber is to install the NameService as ram_copies.
-           This option makes it possible to change this to disc_copies. But
-           the user should be aware of that if a node is restarted, all
-           local object references stored in the NameService is not valid.
-           Hence, you cannot switch to disc_copies and expect exactly the same
-           behavior as before.</item>
-          <item><c>{load_order, Priority}</c> - per default the priority is set to 0.
-           Using this option it will change the priority of in which order
-           Mnesia will load Orber internal tables. For more information,
-           consult the Mnesia documentation.</item>
-        </list>
-      </desc>
-    </func>
-    <func>
-      <name>uninstall() -> ok</name>
-      <fsummary>Uninstall the Orber application</fsummary>
-      <desc>
-        <p>This function stops the Orber application, terminates all server
-          objects and removes all Orber related mnesia tables.</p>
-        <p>Note: Since other applications may be running on the same node
-          using mnesia <em>uninstall</em> will not stop the mnesia application.</p>
-      </desc>
-    </func>
-    <func>
-      <name>add_node(Node, Options) -> RetVal</name>
-      <fsummary>Add a new node to a group of Orber nodes.</fsummary>
-      <type>
-        <v>Node = node()</v>
-        <v>Options = IFRStorageType | [KeyValue] </v>
-        <v>IFRStorageType = StorageType</v>
-        <v>StorageType = disc_copies | ram_copies</v>
-        <v>KeyValue = {ifr_storage_type, StorageType} |  {initialreferences_storage_type, StorageType} |  {nameservice_storage_type, StorageType} |  {type, Type} </v>
-        <v>Type = temporary | permanent</v>
-        <v>RetVal = ok | exit()</v>
-      </type>
-      <desc>
-        <p>This function add given node to a existing Orber node group and starts
-          Orber on the new node. <c>orber:add_node</c> is called from a member in the Orber
-          node group.</p>
-        <p>Preconditions for new node:</p>
-        <list type="bulleted">
-          <item>Erlang started on the new node using the option <c>-mnesia extra_db_nodes</c>, e.g.,
-          <c>erl -sname new_node_name -mnesia extra_db_nodes ConnectToNodes_List</c></item>
-          <item>The new node's <c>domain</c> name is the same for the nodes we want to connect to.</item>
-          <item>Mnesia is running on the new node (no new schema created).</item>
-          <item>If the new node will use <c>disc_copies</c> the schema type must be changed using:
-          <c>mnesia:change_table_copy_type(schema, node(), disc_copies).</c></item>
-        </list>
-        <p>Orber will be started by the function on the new node.</p>
-        <p>Fails if:</p>
-        <list type="bulleted">
-          <item>Orber already installed on given node.</item>
-          <item>Mnesia not started as described above on the new node.</item>
-          <item>Impossible to copy data in Mnesia tables to the new node.</item>
-          <item>Not able to start Orber on the new node, due to, for example, the 
-          <c>iiop_port</c> is already in use.</item>
-        </list>
-        <p>The function do not remove already copied tables after a failure.
-          Use <c>orber:remove_node</c> to remove these tables.</p>
-      </desc>
-    </func>
-    <func>
-      <name>remove_node(Node) -> RetVal</name>
-      <fsummary>Removes a node from a group of Orber nodes.</fsummary>
-      <type>
-        <v>Node = node()</v>
-        <v>RetVal = ok | exit()</v>
-      </type>
-      <desc>
-        <p>This function removes given node from a Orber node group. The Mnesia
-          application is not stopped.</p>
-      </desc>
-    </func>
-    <func>
-      <name>configure(Key, Value) -> ok | {'EXIT', Reason}</name>
-      <fsummary>Change Orber configuration.</fsummary>
-      <type>
-        <v>Key = orbDefaultInitRef | orbInitRef | giop_version | iiop_timeout | iiop_connection_timeout | iiop_setup_connection_timeout | iiop_in_connection_timeout | objectkeys_gc_time | orber_debug_level</v>
-        <v>Value = allowed value associated with the given key</v>
-      </type>
-      <desc>
-        <p>This function allows the user to configure Orber in, for example,
-          an Erlang shell. It is possible to invoke <c>configure</c> at any time
-          the keys specified above.</p>
-        <p>Any other key must be set before installing and starting Orber.</p>
-        <p>Trying to change the configuration in any other way is <em>NOT</em>
-          allowed since it may affect the behavior of Orber.</p>
-        <p>For more information regarding allowed values, see
-          <seealso marker="ch_install#config">configuration settings</seealso>
-          in the User's Guide.</p>
-        <p></p>
-        <note>
-          <p>Configuring the IIOP timeout values will not affect already
-            existing connections. If you want a guaranteed uniform behavior, you
-            must set these parameters from the start.</p>
-        </note>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/orber_acl.xml b/lib/orber/doc/src/orber_acl.xml
deleted file mode 100644
index 5feda83ef6..0000000000
--- a/lib/orber/doc/src/orber_acl.xml
+++ /dev/null
@@ -1,107 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>2005</year>
-      <year>2016</year>
-      <holder>Ericsson AB, All Rights Reserved</holder>
-    </copyright>
-    <legalnotice>
-  Licensed under the Apache License, Version 2.0 (the "License");
-  you may not use this file except in compliance with the License.
-  You may obtain a copy of the License at
- 
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
-
-  The Initial Developer of the Original Code is Ericsson AB.
-    </legalnotice>
-
-    <title>orber_acl</title>
-    <prepared></prepared>
-    <responsible></responsible>
-    <docno></docno>
-    <approved></approved>
-    <checked></checked>
-    <date>2005-05-19</date>
-    <rev>A</rev>
-  </header>
-  <module>orber_acl</module>
-  <modulesummary>Orber ACL operations</modulesummary>
-  <description>
-    <p>This module contains functions intended for analyzing Access 
-      Control List (ACL) filters. The filters uses a extended format of 
-      Classless Inter Domain Routing (CIDR). 
-      For example, <c>"123.123.123.10"</c> limits
-      the connection to that particular host, while <c>"123.123.123.10/17"</c> allows
-      connections to or from any host equal to the 17 most significant bits. Orber
-      also allow the user to specify a certain port or port range, for example,
-      <c>"123.123.123.10/17#4001"</c> and <c>"123.123.123.10/17#4001/5001"</c>
-      respectively. IPv4 or none compressed IPv6 strings are accepted.</p>
-  </description>
-  <funcs>
-    <func>
-      <name>match(IP, Direction) -> boolean()</name>
-      <name>match(IP, Direction, GetInfo) -> Reply</name>
-      <fsummary>Verify if the IP address versus the current configuration</fsummary>
-      <type>
-        <v>IP = tuple() | [integer()]</v>
-        <v>Direction = tcp_in | ssl_in | tcp_out | ssl_out</v>
-        <v>GetInfo = boolean()</v>
-        <v>Reply = boolean() | {boolean(), [Interface], PortInfo}</v>
-        <v>Interface = string()</v>
-        <v>PortInfo = integer() | {integer(), integer()}</v>
-      </type>
-      <desc>
-        <p>If <c>GetInfo</c> is not supplied or set to false, this operation returns
-          a boolean which tells if the IPv4 or IPv6 address would pass the ACL
-          filter, defined by the <c>iiop_acl</c> configuration parameter, or not.
-          When <c>GetInfo</c> is set to true, a tuple which, besides the boolean
-          that tells if access was granted, also include the defined
-          interfaces and port(s). This operation requires that Orber is running and
-          can be used on a live node to determine if Orber has been properly configured.</p>
-      </desc>
-    </func>
-    <func>
-      <name>verify(IP, Filter, Family) -> Reply</name>
-      <fsummary>Verify if the IP address versus the Filter</fsummary>
-      <type>
-        <v>IP = string()</v>
-        <v>Filter = string()</v>
-        <v>Family = inet | inet6</v>
-        <v>Reply = true | {false, From, To} | {error, string()}</v>
-        <v>From = string()</v>
-        <v>To = string()</v>
-      </type>
-      <desc>
-        <p>This operation returns true if the IPv4 or IPv6 address would pass the
-          supplied ACL. If that is not the case, a tuple containing the accepted range
-          is returned. This operation should only be used for test purposes.</p>
-      </desc>
-    </func>
-    <func>
-      <name>range(Filter, Family) -> Reply</name>
-      <fsummary>Get range of Filter</fsummary>
-      <type>
-        <v>Filter = string()</v>
-        <v>Family = inet | inet6</v>
-        <v>Reply = {ok, From, To} | {error, string()}</v>
-        <v>From = string()</v>
-        <v>To = string()</v>
-      </type>
-      <desc>
-        <p>Returns the range of accepted IP addresses based on the supplied filter. 
-          This operation should only be used for test purposes.</p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/orber_diagnostics.xml b/lib/orber/doc/src/orber_diagnostics.xml
deleted file mode 100644
index 3aad304535..0000000000
--- a/lib/orber/doc/src/orber_diagnostics.xml
+++ /dev/null
@@ -1,81 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>2003</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>orber_diagnostics</title>
-    <prepared></prepared>
-    <responsible></responsible>
-    <docno></docno>
-    <approved></approved>
-    <checked></checked>
-    <date>2003-04-17</date>
-    <rev>A</rev>
-  </header>
-  <module>orber_diagnostics</module>
-  <modulesummary>Diagnostics API for Orber</modulesummary>
-  <description>
-    <p>This module contains functions which makes it possible to run simple
-      tests.</p>
-    <p></p>
-    <warning>
-      <p>Functions exported by this module may only be used during
-        test and development phase.</p>
-    </warning>
-  </description>
-  <funcs>
-    <func>
-      <name>nameservice() -> Result</name>
-      <name>nameservice(Flags) -> Result</name>
-      <fsummary>Display all objects stored in the Name Service</fsummary>
-      <type>
-        <v>Flags = integer()</v>
-        <v>Result = ok | {'EXCEPTION', E}</v>
-      </type>
-      <desc>
-        <p>Displays all objects stored in the NameService. Existent checks are, per 
-          default, also performed on all local objects. This can also be activated 
-          for external objects by setting the flag <c>16#01</c>. The displayed
-          information is the stringified Name described in 
-          <seealso marker="CosNaming_NamingContextExt">CosNaming_NamingContextExt</seealso>,
-          non existent status (true | false | external | undefined) and the IFR-Id:</p>
-        <code type="none">
-host/
-host/resources/
-host/resources/MyObj/ [false] IDL:MyMod/MyIntf:1.0        </code>
-      </desc>
-    </func>
-    <func>
-      <name>missing_modules() -> Count</name>
-      <fsummary>Echo missing modules required by Orber</fsummary>
-      <type>
-        <v>Count = integer()</v>
-      </type>
-      <desc>
-        <p>This operation list missing modules generated by IC and required by
-          Orber. Requires that all API:s are registered in the IFR.</p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/orber_ifr.xml b/lib/orber/doc/src/orber_ifr.xml
deleted file mode 100644
index a667d7d9e4..0000000000
--- a/lib/orber/doc/src/orber_ifr.xml
+++ /dev/null
@@ -1,1035 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>1997</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>orber_ifr</title>
-    <prepared></prepared>
-    <docno></docno>
-    <approved></approved>
-    <checked></checked>
-    <date>1997-10-13</date>
-    <rev>A</rev>
-  </header>
-  <module>orber_ifr</module>
-  <modulesummary>The Interface Repository stores representations of IDL information</modulesummary>
-  <description>
-    <p>This module contains functions for managing the Interface
-      Repository (IFR). This documentation should be used in conjunction
-      with the documentation in chapter 6 of <term id="CORBA"></term>2.3.
-      Whenever the term IFR object is used in this manual page, it
-      refers to a pseudo object used only for interaction with the IFR
-      rather than a CORBA object.</p>
-  </description>
-
-  <section>
-    <title>Initialization of the IFR</title>
-    <p>The following functions are used to initialize the Interface
-      Repository and to obtain the initial reference to the
-      repository.</p>
-  </section>
-  <funcs>
-    <func>
-      <name>init(Nodes,Timeout) -> ok</name>
-      <fsummary>Intialize the IFR</fsummary>
-      <type>
-        <v>Nodes = list()</v>
-        <v>Timeout = integer() | infinity</v>
-      </type>
-      <desc>
-        <p>This function should be called to initialize the IFR. It
-          creates the necessary mnesia-tables. A mnesia schema should
-          exist, and mnesia must be running.</p>
-      </desc>
-    </func>
-    <func>
-      <name>find_repository() -> #IFR_Repository_objref</name>
-      <fsummary>Find the IFR object reference for the Repository</fsummary>
-      <desc>
-        <p>Find the IFR object reference for the Repository. This
-          reference should be used when adding objects to the IFR, and
-          when extracting information from the IFR.
-          The first time this function is called, it will create the
-          repository and all the primitive definitions.</p>
-      </desc>
-    </func>
-  </funcs>
-
-  <section>
-    <title>General methods</title>
-    <p>The following functions are the methods of the IFR. The first
-      argument is always an #IFR_objref, i.e. the IFR (pseudo)object
-      on which to apply this method. These functions are useful when
-      the type of IFR object is not know, but they are somewhat slower
-      than the specific functions listed below which only accept a
-      particular type of IFR object as the first argument.</p>
-  </section>
-  <funcs>
-    <func>
-      <name>get_def_kind(Objref) -> Return</name>
-      <fsummary>Return the definition kind of the IFR object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Return = atom() (one of dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Wstring, dk_Fixed, dk_Sequence, dk_Array, dk_Repository)</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind. Returns the definition
-          kind of the IFR object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>destroy(Objref) -> Return</name>
-      <fsummary>Destroy, except IRObject, Contained and Container, target object and its contents</fsummary>
-      <type>
-        <v>Objref = #IFR_object</v>
-        <v>Return = tuple()</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind except IRObject,
-          Contained and Container. Destroys that object and its
-          contents (if any). Returns whatever mnesia:transaction
-          returns.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_id(Objref) -> Return</name>
-      <fsummary>Return the target object's repository id</fsummary>
-      <type>
-        <v>Objref = #IFR_object</v>
-        <v>Return = string()</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Contained. Returns the repository id of that object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_id(Objref,Id) -> ok</name>
-      <fsummary>Set the target object's repository id</fsummary>
-      <type>
-        <v>Objref = #IFR_object</v>
-        <v>Id = string()</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Contained. Sets the repository id of that object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_name(Objref) -> Return</name>
-      <fsummary>Return the name of the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_object</v>
-        <v>Return = string()</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Contained. Returns the name of that object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_name(Objref,Name) -> ok</name>
-      <fsummary>Set given name to target object</fsummary>
-      <type>
-        <v>Objref = #IFR_object</v>
-        <v>Name = string()</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Contained. Sets the name of that object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_version(Objref) -> Return</name>
-      <fsummary>Return the version of the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_object</v>
-        <v>Return = string()</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Contained. Returns the version of that object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_version(Objref,Version) -> ok</name>
-      <fsummary>Set given version of the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_object</v>
-        <v>Version = string()</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Contained. Sets the version of that object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_defined_in(Objref) -> Return</name>
-      <fsummary>Return the Container the target object is contained in</fsummary>
-      <type>
-        <v>Objref = #IFR_object</v>
-        <v>Return = #IFR_Container_objref</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Contained. Returns the Container object that the object is
-          defined in.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_absolute_name(Objref) -> Return</name>
-      <fsummary>Return the absolute name of the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_object</v>
-        <v>Return = string()</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Contained. Returns the absolute (scoped) name of that
-          object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_containing_repository(Objref) -> Return</name>
-      <fsummary>Get the most derived Contained object associated  with the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_object</v>
-        <v>Return = #IFR_Repository_objref</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Contained. Returns the Repository that is eventually reached
-          by recursively following the object's defined_in attribute.</p>
-      </desc>
-    </func>
-    <func>
-      <name>describe(Objref) -> Return</name>
-      <fsummary>Return a tuple which describe the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_object</v>
-        <v>Return = tuple() (a contained_description record) | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Contained. Returns a tuple describing the object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>move(Objref,New_container,New_name,New_version) -> Return</name>
-      <fsummary>Move the target object from its current location to given  Container, name and version</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>New_container = #IFR_Container_objref</v>
-        <v>New_name = string()</v>
-        <v>New_version = string()</v>
-        <v>Return = ok | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Contained. New_container is an IFR object of any kind that
-          inherits from Container. Removes Objref from its current 
-          Container, and adds it to New_container. The name attribute
-          is changed to New_name and the version attribute is changed
-          to New_version.</p>
-      </desc>
-    </func>
-    <func>
-      <name>lookup(Objref,Search_name) -> Return</name>
-      <fsummary>Return the IFR object identified by the given name</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Search_name = string()</v>
-        <v>Return =  #IFR_object</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Container. Returns an IFR object identified by search_name
-          (a scoped name).</p>
-      </desc>
-    </func>
-    <func>
-      <name>contents(Objref,Limit_type,Exclude_inherited) -> Return</name>
-      <fsummary>Return the content of the target object limited by the given constraints</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Limit_type = atom() (one of dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Wstring, dk_Fixed, dk_Sequence, dk_Array, dk_Repository)</v>
-        <v>Exclude_inherited = atom() (true or false)</v>
-        <v>Return = list() (a list of IFR#_objects)</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Container. Returns the contents of that IFR object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>lookup_name(Objref,Search_name,Levels_to_search, Limit_type, Exclude_inherited) -> Return</name>
-      <fsummary>Return a list of IFR objects matching the given name</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Search_name = string()</v>
-        <v>Levels_to_search = integer()</v>
-        <v>Limit_type = atom() (one of dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Wstring, dk_Fixed, dk_Sequence,  dk_Array, dk_Repository)</v>
-        <v>Exclude_inherited = atom() (true or false)</v>
-        <v>Return = list() (a list of #IFR_objects)</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Container. Returns a list of #IFR_objects with an id
-          matching Search_name.</p>
-      </desc>
-    </func>
-    <func>
-      <name>describe_contents(Objref, Limit_type, Exclude_inherited, Max_returned_objs) -> Return</name>
-      <fsummary>Return a list of descriptions of the IFR objects contained by the target Container object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Limit_type = atom() (one of dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Wstring, dk_Fixed, dk_Sequence, dk_Array, dk_Repository)</v>
-        <v>Exclude_inherited = atom() (true or false)</v>
-        <v>Return = list() (a list of tuples (contained_description records) | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Container. Returns a list of descriptions of the IFR objects
-          in this Container's contents.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_module(Objref,Id,Name,Version) -> Return</name>
-      <fsummary>Create an IFR object of given type</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Id = string()</v>
-        <v>Name = string()</v>
-        <v>Version = string()</v>
-        <v>Return = #IFR_ModuleDef_objref</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Container. Creates an IFR object of the type ModuleDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_constant(Objref,Id,Name,Version,Type,Value) -> Return</name>
-      <fsummary>Create a ConstantDef IFR object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Id = string()</v>
-        <v>Name = string()</v>
-        <v>Version = string()</v>
-        <v>Type = #IFR_IDLType_objref</v>
-        <v>Value = any()</v>
-        <v>Return = #IFR_ConstantDef_objref</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Container. Creates an IFR object of the type ConstantDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_struct(Objref,Id,Name,Version,Members) -> Return</name>
-      <fsummary>Create a StructDef IFR object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Id = string()</v>
-        <v>Name = string()</v>
-        <v>Version = string()</v>
-        <v>Members = list() (list of structmember records)</v>
-        <v>Return = #IFR_StructDef_objref</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Container. Creates an IFR object of the type StructDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_union(Objref,Id,Name,Version,Discriminator_type,Members) -> Return</name>
-      <fsummary>Create a UnionDef IFR object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Id = string()</v>
-        <v>Name = string()</v>
-        <v>Version = string()</v>
-        <v>Discriminator_type = #IFR_IDLType_Objref</v>
-        <v>Members = list() (list of unionmember records)</v>
-        <v>Return = #IFR_UnionDef_objref</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Container. Creates an IFR object of the type UnionDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_enum(Objref,Id,Name,Version,Members) -> Return</name>
-      <fsummary>Create a EnumDef IFR object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Id = string()</v>
-        <v>Name = string()</v>
-        <v>Version = string()</v>
-        <v>Members = list() (list of strings)</v>
-        <v>Return = #IFR_EnumDef_objref</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Container. Creates an IFR object of the type EnumDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_alias(Objref,Id,Name,Version,Original_type) -> Return</name>
-      <fsummary>Create a AliasDef IFR object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Id = string()</v>
-        <v>Name = string()</v>
-        <v>Version = string()</v>
-        <v>Original_type = #IFR_IDLType_Objref</v>
-        <v>Return = #IFR_AliasDef_objref</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Container. Creates an IFR object of the type AliasDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_interface(Objref,Id,Name,Version,Base_interfaces) -> Return</name>
-      <fsummary>Create a InterfaceDef IFR object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Id = string()</v>
-        <v>Name = string()</v>
-        <v>Version = string()</v>
-        <v>Base_interfaces = list() (a list of IFR_InterfaceDef_objrefs that this interface inherits from</v>
-        <v>Return = #IFR_InterfaceDef_objref</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Container. Creates an IFR object of the type InterfaceDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_exception(Objref,Id,Name,Version,Members) -> Return</name>
-      <fsummary>Create a ExceptionDef IFR object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Id = string()</v>
-        <v>Name = string()</v>
-        <v>Version = string()</v>
-        <v>Members = list() (list of structmember records)</v>
-        <v>Return = #IFR_ExceptionDef_objref</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          Container. Creates an IFR object of the type ExceptionDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_type(Objref) -> Return</name>
-      <fsummary>Return the typecode of the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Return = tuple() (a typecode tuple)</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of any kind that inherits from
-          IDLType or an IFR object of the kind ConstantDef,
-          ExceptionDef or AttributeDef. Returns the typecode of the
-          IFR object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>lookup_id(Objref,Search_id) -> Return</name>
-      <fsummary>Return the IFR object matching the given id</fsummary>
-      <type>
-        <v>Objref = #IFR_Repository_objref</v>
-        <v>Search_id = string()</v>
-        <v>Return = #IFR_objref</v>
-      </type>
-      <desc>
-        <p>Returns an IFR object matching the Search_id.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_primitive(Objref,Kind) -> Return</name>
-      <fsummary>Return a PrimitiveDef of the specified kind</fsummary>
-      <type>
-        <v>Objref = #IFR_Repository_objref</v>
-        <v>Kind = atom() (one of pk_null, pk_void, pk_short, pk_long, pk_ushort, pk_ulong, pk_float, pk_double, pk_boolean, pk_char, pk_octet, pk_any, pk_TypeCode, pk_Principal, pk_string, pk_wstring, pk_fixed, pk_objref)</v>
-        <v>Return = #IFR_PrimitiveDef_objref</v>
-      </type>
-      <desc>
-        <p>Returns a PrimitiveDef of the specified kind.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_string(Objref,Bound) -> Return</name>
-      <fsummary>Create an IFR objref of the type StringDef</fsummary>
-      <type>
-        <v>Objref = #IFR_Repository_objref</v>
-        <v>Bound = integer() (unsigned long /= 0)</v>
-        <v>Return = #IFR_StringDef_objref</v>
-      </type>
-      <desc>
-        <p>Creates an IFR objref of the type StringDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_wstring(Objref,Bound) -> Return</name>
-      <fsummary>Create an IFR objref of the type WstringDef</fsummary>
-      <type>
-        <v>Objref = #IFR_Repository_objref</v>
-        <v>Bound = integer() (unsigned long /= 0)</v>
-        <v>Return = #IFR_WstringDef_objref</v>
-      </type>
-      <desc>
-        <p>Creates an IFR objref of the type WstringDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_fixed(Objref,Digits,Scale) -> Return</name>
-      <fsummary>Create an IFR objref of the type FixedDef</fsummary>
-      <type>
-        <v>Objref = #IFR_Repository_objref</v>
-        <v>Digits = Scale = integer()</v>
-        <v>Return = #IFR_FixedDef_objref</v>
-      </type>
-      <desc>
-        <p>Creates an IFR objref of the type FixedDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_sequence(Objref,Bound,Element_type) -> Return</name>
-      <fsummary>Create an IFR objref of the type SequenceDef</fsummary>
-      <type>
-        <v>Objref = #IFR_Repository_objref</v>
-        <v>Bound = integer() (unsigned long)</v>
-        <v>Element_type = #IFR_IDLType_objref</v>
-        <v>Return = #IFR_SequenceDef_objref</v>
-      </type>
-      <desc>
-        <p>Creates an IFR objref of the type SequenceDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_array(Objref,Length,Element_type) -> Return</name>
-      <fsummary>Create an IFR objref of the type ArrayDef</fsummary>
-      <type>
-        <v>Objref = #IFR_Repository_objref</v>
-        <v>Bound = integer() (unsigned long)</v>
-        <v>Element_type = #IFR_IDLType_objref</v>
-        <v>Return = #IFR_ArrayDef_objref</v>
-      </type>
-      <desc>
-        <p>Creates an IFR objref of the type ArrayDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_idltype(Objref,Typecode) -> Return</name>
-      <fsummary>Create an IFR objref of the type IDLType</fsummary>
-      <type>
-        <v>Objref = #IFR_Repository_objref</v>
-        <v>Typecode = tuple() (a typecode tuple)</v>
-        <v>Return = #IFR_IDLType_objref</v>
-      </type>
-      <desc>
-        <p>Creates an IFR objref of the type IDLType.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_type_def(Objref) -> Return</name>
-      <fsummary>Return an IFR object of the type IDLType describing the  type of the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Return = #IFR_IDLType_objref</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of the kind ConstantDef or
-          AttributeDef. Returns an IFR object of the type IDLType
-          describing the type of the IFR object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_type_def(Objref,TypeDef) -> Return</name>
-      <fsummary>Set given TypeDef of the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>TypeDef = #IFR_IDLType_objref</v>
-        <v>Return = ok | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object of the kind ConstantDef or
-          AttributeDef. Sets the type_def of the IFR Object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_value(Objref) -> Return</name>
-      <fsummary>Return the value attribute of the target ConstantDef object</fsummary>
-      <type>
-        <v>Objref = #IFR_ConstantDef_objref</v>
-        <v>Return = any()</v>
-      </type>
-      <desc>
-        <p>Returns the value attribute of an IFR Object of the type ConstantDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_value(Objref,Value) -> Return</name>
-      <fsummary>Set the value attribute of the target ConstantDef object</fsummary>
-      <type>
-        <v>Objref = #IFR_ConstantDef_objref</v>
-        <v>Value = any()</v>
-        <v>Return = ok | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Sets the value attribute of an IFR Object of the type ConstantDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_members(Objref) -> Return</name>
-      <fsummary>Return the members of the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Return = list()</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object the kind StructDef, UnionDef,
-          EnumDef or ExceptionDef.
-          For StructDef, UnionDef and ExceptionDef: Returns a list of
-          structmember records that are the constituent parts of the
-          object.
-          For EnumDef: Returns a list of strings describing the
-          enumerations.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_members(Objref,Members) -> Return</name>
-      <fsummary>Set the members attribute of the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Members = list()</v>
-        <v>Return = ok | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object the kind StructDef, UnionDef,
-          EnumDef or ExceptionDef.
-          For StructDef, UnionDef and ExceptionDef: Members is a list
-          of structmember records.
-          For EnumDef: Members is a list of strings describing the
-          enumerations.
-          Sets the members attribute, which are the constituent parts of the
-          exception.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_discriminator_type(Objref) -> Return</name>
-      <fsummary>Get the discriminator typecode of the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_UnionDef_objref</v>
-        <v>Return = tuple() (a typecode tuple)</v>
-      </type>
-      <desc>
-        <p>Returns the discriminator typecode of an IFR object of the type
-          UnionDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_discriminator_type_def(Objref) -> Return</name>
-      <fsummary>Return IDLType object describing the discriminator  type of the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_UnionDef_objref</v>
-        <v>Return = #IFR_IDLType_objref</v>
-      </type>
-      <desc>
-        <p>Returns an IFR object of the type IDLType describing the
-          discriminator type of an IFR object of the type UnionDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_discriminator_type_def(Objref,TypeDef) ->  Return</name>
-      <fsummary>Set the attribute discriminator_type_def for the target object to the given TypeDef</fsummary>
-      <type>
-        <v>Objref = #IFR_UnionDef_objref</v>
-        <v>Return = #IFR_IDLType_objref</v>
-      </type>
-      <desc>
-        <p>Sets the attribute discriminator_type_def, an IFR object of
-          the type IDLType describing the discriminator type of an IFR
-          object of the type UnionDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_original_type_def(Objref) -> Return</name>
-      <fsummary>Return an IFR object of the type IDLType describing the original type</fsummary>
-      <type>
-        <v>Objref = #IFR_AliasDef_objref</v>
-        <v>Return = #IFR_IDLType_objref</v>
-      </type>
-      <desc>
-        <p>Returns an IFR object of the type IDLType describing the
-          original type.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_original_type_def(Objref,TypeDef) -> Return</name>
-      <fsummary>Set the original_type_def attribute which describes the  original type</fsummary>
-      <type>
-        <v>Objref = #IFR_AliasDef_objref</v>
-        <v>Typedef = #IFR_IDLType_objref</v>
-        <v>Return = ok | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Sets the original_type_def attribute which describes the
-          original type.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_kind(Objref) -> Return</name>
-      <fsummary>Return an atom describing the primitive type</fsummary>
-      <type>
-        <v>Objref = #IFR_PrimitiveDef_objref</v>
-        <v>Return = atom()</v>
-      </type>
-      <desc>
-        <p>Returns an atom describing the primitive type (See CORBA 2.0
-          p 6-21).</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_bound(Objref) -> Return</name>
-      <fsummary>Get the maximum size of the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Return = integer (unsigned long)</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object the kind StringDef or SequenceDef.
-          For StringDef: returns the maximum number of characters in
-          the string.
-          For SequenceDef: Returns the maximum number of elements in
-          the sequence. Zero indicates an unbounded sequence.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_bound(Objref,Bound) -> Return</name>
-      <fsummary>Set the maximum size of the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Bound = integer (unsigned long)</v>
-        <v>Return = ok | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object the kind StringDef or SequenceDef.
-          For StringDef: Sets the maximum number of characters in the
-          string. Bound must not be zero.
-          For SequenceDef: Sets the maximum number of elements in the
-          sequence. Zero indicates an unbounded sequence.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_element_type(Objref) -> Return</name>
-      <fsummary>Return the typecode of the elements in the IFR object</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Return = tuple() (a typecode tuple)</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object the kind SequenceDef or ArrayDef.
-          Returns the typecode of the elements in the IFR object.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_element_type_def(Objref) -> Return</name>
-      <fsummary>Return an IFR object of the type IDLType describing the  type of the elements in Objref</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Return = #IFR_IDLType_objref</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object the kind SequenceDef or ArrayDef.
-          Returns an IFR object of the type IDLType describing the
-          type of the elements in Objref.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_element_type_def(Objref,TypeDef) -> Return</name>
-      <fsummary>Set the element_type_def attribute of the target object to the given TypeDef</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>TypeDef = #IFR_IDLType_objref</v>
-        <v>Return = ok | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object the kind SequenceDef or ArrayDef.
-          Sets the element_type_def attribute, an IFR object of the
-          type IDLType describing the type of the elements in Objref.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_length(Objref) -> Return</name>
-      <fsummary>Return the number of elements in the array</fsummary>
-      <type>
-        <v>Objref = #IFR_ArrayDef_objref</v>
-        <v>Return = integer() (unsigned long)</v>
-      </type>
-      <desc>
-        <p>Returns the number of elements in the array.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_length(Objref,Length) -> Return</name>
-      <fsummary>Set the number of elements in the array</fsummary>
-      <type>
-        <v>Objref = #IFR_ArrayDef_objref</v>
-        <v>Length = integer() (unsigned long)</v>
-      </type>
-      <desc>
-        <p>Sets the number of elements in the array.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_mode(Objref) -> Return</name>
-      <fsummary>Get the mode of the target object (AttributeDef or OperationDef)</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Return = atom()</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object the kind AttributeDef or OperationDef.
-          For AttributeDef: Return is an atom ('ATTR_NORMAL' or
-          'ATTR_READONLY') specifying the read/write access for this
-          attribute.
-          For OperationDef: Return is an atom ('OP_NORMAL' or
-          'OP_ONEWAY') specifying the mode of the operation.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_mode(Objref,Mode) -> Return</name>
-      <fsummary>Set the mode of the target object (AttributeDef or OperationDef) to the given mode</fsummary>
-      <type>
-        <v>Objref = #IFR_objref</v>
-        <v>Mode = atom()</v>
-        <v>Return = ok | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Objref is an IFR object the kind AttributeDef or OperationDef.
-          For AttributeDef: Sets the read/write access for this
-          attribute. Mode is an atom ('ATTR_NORMAL' or
-          'ATTR_READONLY').
-          For OperationDef: Sets the mode of the operation. Mode is an
-          atom ('OP_NORMAL' or 'OP_ONEWAY').</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_result(Objref) -> Return</name>
-      <fsummary>Return typecode describing the type of the value returned by the operation</fsummary>
-      <type>
-        <v>Objref = #IFR_OperationDef_objref</v>
-        <v>Return = tuple() (a typecode tuple)</v>
-      </type>
-      <desc>
-        <p>Returns a typecode describing the type of the value returned by the
-          operation.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_result_def(Objref) -> Return</name>
-      <fsummary>Return an IFR object of the type IDLType describing the  type of the result</fsummary>
-      <type>
-        <v>Objref = #IFR_OperationDef_objref</v>
-        <v>Return = #IFR_IDLType_objref</v>
-      </type>
-      <desc>
-        <p>Returns an IFR object of the type IDLType describing the type of the
-          result.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_result_def(Objref,ResultDef) -> Return</name>
-      <fsummary>Set the type_def attribute of the target object to the given ResultDef</fsummary>
-      <type>
-        <v>Objref = #IFR_OperationDef_objref</v>
-        <v>ResultDef = #IFR_IDLType_objref</v>
-        <v>Return = ok | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Sets the type_def attribute, an IFR Object of the type IDLType
-          describing the result.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_params(Objref) -> Return</name>
-      <fsummary>Return a list of parameter description records describing the parameters of the target OperationDef</fsummary>
-      <type>
-        <v>Objref = #IFR_OperationDef_objref</v>
-        <v>Return = list() (list of parameter description records)</v>
-      </type>
-      <desc>
-        <p>Returns a list of parameter description records, which describes the
-          parameters of the OperationDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_params(Objref,Params) -> Return</name>
-      <fsummary>Set the params attribute of the target object to the given parameter description records</fsummary>
-      <type>
-        <v>Objref = #IFR_OperationDef_objref</v>
-        <v>Params = list() (list of parameter description records)</v>
-        <v>Return = ok | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Sets the params attribute, a list of parameter description records.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_contexts(Objref) -> Return</name>
-      <fsummary>Return a list of context identifiers for the operation</fsummary>
-      <type>
-        <v>Objref = #IFR_OperationDef_objref</v>
-        <v>Return = list() (list of strings)</v>
-      </type>
-      <desc>
-        <p>Returns a list of context identifiers for the operation.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_contexts(Objref,Contexts) -> Return</name>
-      <fsummary>Set the context attribute for the operation</fsummary>
-      <type>
-        <v>Objref = #IFR_OperationDef_objref</v>
-        <v>Contexts = list() (list of strings)</v>
-        <v>Return = ok | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Sets the context attribute for the operation.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_exceptions(Objref) -> Return</name>
-      <fsummary>Return a list of exception types that can be raised  by the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_OperationDef_objref</v>
-        <v>Return = list() (list of #IFR_ExceptionDef_objrefs)</v>
-      </type>
-      <desc>
-        <p>Returns a list of exception types that can be raised by this
-          operation.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_exceptions(Objref,Exceptions) -> Return</name>
-      <fsummary>Set the exceptions attribute for the target object</fsummary>
-      <type>
-        <v>Objref = #IFR_OperationDef_objref</v>
-        <v>Exceptions = list() (list of #IFR_ExceptionDef_objrefs)</v>
-        <v>Return = ok | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Sets the exceptions attribute for this operation.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_base_interfaces(Objref) -> Return</name>
-      <fsummary>Return a list of InterfaceDefs from which the  target InterfaceDef object inherit</fsummary>
-      <type>
-        <v>Objref = #IFR_InterfaceDef_objref</v>
-        <v>Return = list() (list of #IFR_InterfaceDef_objrefs)</v>
-      </type>
-      <desc>
-        <p>Returns a list of InterfaceDefs from which this InterfaceDef inherits.</p>
-      </desc>
-    </func>
-    <func>
-      <name>set_base_interfaces(Objref,BaseInterfaces) -> Return</name>
-      <fsummary>Set the BaseInterfaces attribute</fsummary>
-      <type>
-        <v>Objref = #IFR_InterfaceDef_objref</v>
-        <v>BaseInterfaces = list() (list of #IFR_InterfaceDef_objrefs)</v>
-        <v>Return = ok | {exception, _}</v>
-      </type>
-      <desc>
-        <p>Sets the BaseInterfaces attribute.</p>
-      </desc>
-    </func>
-    <func>
-      <name>is_a(Objref,Interface_id) -> Return</name>
-      <fsummary>Return a boolean if the target InterfaceDef match or inherit from the given id</fsummary>
-      <type>
-        <v>Objref = #IFR_InterfaceDef_objref</v>
-        <v>Interface_id = #IFR_InterfaceDef_objref</v>
-        <v>Return = atom() (true or false)</v>
-      </type>
-      <desc>
-        <p>Returns true if the InterfaceDef either is identical to or
-          inherits from Interface_id.</p>
-      </desc>
-    </func>
-    <func>
-      <name>describe_interface(Objref) -> Return</name>
-      <fsummary>Return a full inter face description record describing the InterfaceDef</fsummary>
-      <type>
-        <v>Objref = #IFR_InterfaceDef_objref</v>
-        <v>Return = tuple() (a fullinterfacedescription record)</v>
-      </type>
-      <desc>
-        <p>Returns a full inter face description record describing the InterfaceDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_attribute(Objref,Id,Name,Version,Type,Mode) -> Return</name>
-      <fsummary>Create an IFR object of the type AttributeDef contained in  the target InterfaceDef object</fsummary>
-      <type>
-        <v>Objref = #IFR_InterfaceDef_objref</v>
-        <v>Id = string()</v>
-        <v>Name = string()</v>
-        <v>Version = string()</v>
-        <v>Type = #IFR_IDLType_objref</v>
-        <v>Mode = atom() ('ATTR_NORMAL' or 'ATTR_READONLY')</v>
-        <v>Return = #IFR_AttributeDef_objref</v>
-      </type>
-      <desc>
-        <p>Creates an IFR object of the type AttributeDef contained in this
-          InterfaceDef.</p>
-      </desc>
-    </func>
-    <func>
-      <name>create_operation(Objref,Id,Name,Version,Result,Mode,Params, Exceptions,Contexts) -> Return</name>
-      <fsummary>Create an IFR object of the type OperationDef contained in the target InterfaceDef object</fsummary>
-      <type>
-        <v>Objref = #IFR_InterfaceDef_objref</v>
-        <v>Id = string()</v>
-        <v>Name = string()</v>
-        <v>Version = string()</v>
-        <v>Result = #IFR_IDLType_objref</v>
-        <v>Mode = atom() ('OP_NORMAL' or 'OP_ONEWAY')</v>
-        <v>Params = list() (list of parameter description records)</v>
-        <v>Exceptions = list() (list of #IFR_ExceptionDef_objrefs)</v>
-        <v>Contexts = list() (list of strings)</v>
-        <v>Return = #IFR_OperationDef_objref</v>
-      </type>
-      <desc>
-        <p>Creates an IFR object of the type OperationDef contained in this
-          InterfaceDef.</p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/orber_tc.xml b/lib/orber/doc/src/orber_tc.xml
deleted file mode 100644
index 0cab8a5e4b..0000000000
--- a/lib/orber/doc/src/orber_tc.xml
+++ /dev/null
@@ -1,259 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
-  <header>
-    <copyright>
-      <year>1998</year>
-      <year>2016</year>
-      <holder>Ericsson AB, All Rights Reserved</holder>
-    </copyright>
-    <legalnotice>
-  Licensed under the Apache License, Version 2.0 (the "License");
-  you may not use this file except in compliance with the License.
-  You may obtain a copy of the License at
- 
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
-
-  The Initial Developer of the Original Code is Ericsson AB.
-    </legalnotice>
-
-    <title>orber_tc</title>
-    <prepared>Lars Thors&eacute;n</prepared>
-    <responsible>Lars Thors&eacute;n</responsible>
-    <docno></docno>
-    <approved>Lars Thors&eacute;n</approved>
-    <checked></checked>
-    <date>1998-04-20</date>
-    <rev>A</rev>
-  </header>
-  <module>orber_tc</module>
-  <modulesummary>Help functions for IDL typecodes</modulesummary>
-  <description>
-    <p>This module contains some functions that gives support in creating 
-      IDL typecodes that can be used in for example the any types typecode field.
-      For the simple types it is meaningless to use this API but the functions exist
-      to get the interface complete.</p>
-    <p>The type <c>TC</c> used below describes an IDL type and is a tuple according 
-      to the to the Erlang language mapping.</p>
-  </description>
-  <funcs>
-    <func>
-      <name>null() -> TC</name>
-      <name>void() -> TC</name>
-      <name>short() -> TC</name>
-      <name>unsigned_short() -> TC</name>
-      <name>long() -> TC</name>
-      <name>unsigned_long() -> TC</name>
-      <name>long_long() -> TC</name>
-      <name>unsigned_long_long() -> TC</name>
-      <name>wchar() -> TC</name>
-      <name>float() -> TC</name>
-      <name>double() -> TC</name>
-      <name>boolean() -> TC</name>
-      <name>char() -> TC</name>
-      <name>octet() -> TC</name>
-      <name>any() -> TC</name>
-      <name>typecode() -> TC</name>
-      <name>principal() -> TC</name>
-      <fsummary>Return the IDL typecode</fsummary>
-      <desc>
-        <p>These functions return the IDL typecodes for simple types.</p>
-      </desc>
-    </func>
-    <func>
-      <name>object_reference(Id, Name) -> TC</name>
-      <fsummary>Return the object_reference IDL typecode</fsummary>
-      <type>
-        <v>Id = string()</v>
-        <d>the repository ID</d>
-        <v>Name = string()</v>
-        <d>the type name of the object</d>
-      </type>
-      <desc>
-        <p>Function returns the IDL typecode for object_reference.</p>
-      </desc>
-    </func>
-    <func>
-      <name>struct(Id, Name, ElementList) -> TC</name>
-      <fsummary>Return the struct IDL typecode</fsummary>
-      <type>
-        <v>Id = string()</v>
-        <d>the repository ID</d>
-        <v>Name = string()</v>
-        <d>the type name of the struct</d>
-        <v>ElementList = [{MemberName, TC}]</v>
-        <d>a list of the struct elements</d>
-        <v>MemberName = string()</v>
-        <d>the element name</d>
-      </type>
-      <desc>
-        <p>Function returns the IDL typecode for struct.</p>
-      </desc>
-    </func>
-    <func>
-      <name>union(Id, Name, DiscrTC, Default, ElementList) -> TC</name>
-      <fsummary>Return the union IDL typecode</fsummary>
-      <type>
-        <v>Id = string()</v>
-        <d>the repository ID</d>
-        <v>Name = string()</v>
-        <d>the type name of the union</d>
-        <v>DiscrTC = TC</v>
-        <d>the typecode for the unions discriminant</d>
-        <v>Default = integer()</v>
-        <d>a value that indicates which tuple in the element list that is default (value &lt; 0 means no default)</d>
-        <v>ElementList = [{Label, MemberName, TC}]</v>
-        <d>a list of the union elements</d>
-        <v>Label = term()</v>
-        <d>the label value should be of the <em>DiscrTC</em>type</d>
-        <v>MemberName = string()</v>
-        <d>the element name</d>
-      </type>
-      <desc>
-        <p>Function returns the IDL typecode for union.</p>
-      </desc>
-    </func>
-    <func>
-      <name>enum(Id, Name, ElementList) -> TC</name>
-      <fsummary>Return the enum IDL typecode</fsummary>
-      <type>
-        <v>Id = string()</v>
-        <d>the repository ID</d>
-        <v>Name = string()</v>
-        <d>the type name of the enum</d>
-        <v>ElementList = [MemberName]</v>
-        <d>a list of the enums elements</d>
-        <v>MemberName = string()</v>
-        <d>the element name</d>
-      </type>
-      <desc>
-        <p>Function returns the IDL typecode for enum.</p>
-      </desc>
-    </func>
-    <func>
-      <name>string(Length) -> TC</name>
-      <fsummary>Return the string IDL typecode</fsummary>
-      <type>
-        <v>Length = integer()</v>
-        <d>the length of the string (0 means unbounded)</d>
-      </type>
-      <desc>
-        <p>Function returns the IDL typecode for string.</p>
-      </desc>
-    </func>
-    <func>
-      <name>wstring(Length) -> TC</name>
-      <fsummary>Return the wstring IDL typecode</fsummary>
-      <type>
-        <v>Length = integer()</v>
-        <d>the length of the wstring (0 means unbounded)</d>
-      </type>
-      <desc>
-        <p>Function returns the IDL typecode for wstring.</p>
-      </desc>
-    </func>
-    <func>
-      <name>fixed(Digits, Scale) -> TC</name>
-      <fsummary>Return the fixed IDL typecode</fsummary>
-      <type>
-        <v>Digits = Scale = integer()</v>
-        <d>the digits and scale parameters of a Fixed type</d>
-      </type>
-      <desc>
-        <p>Function returns the IDL typecode for fixed.</p>
-      </desc>
-    </func>
-    <func>
-      <name>sequence(ElemTC, Length) -> TC</name>
-      <fsummary>Return the sequence IDL typecode</fsummary>
-      <type>
-        <v>ElemTC = TC</v>
-        <d>the typecode for the sequence elements</d>
-        <v>Length = integer()</v>
-        <d>the length of the sequence (0 means unbounded)</d>
-      </type>
-      <desc>
-        <p>Function returns the IDL typecode for sequence.</p>
-      </desc>
-    </func>
-    <func>
-      <name>array(ElemTC, Length) -> TC</name>
-      <fsummary>Return the array IDL typecode</fsummary>
-      <type>
-        <v>ElemTC = TC</v>
-        <d>the typecode for the array elements</d>
-        <v>Length = integer()</v>
-        <d>the length of the array</d>
-      </type>
-      <desc>
-        <p>Function returns the IDL typecode for array.</p>
-      </desc>
-    </func>
-    <func>
-      <name>alias(Id, Name, AliasTC) -> TC</name>
-      <fsummary>Return the alias IDL typecode</fsummary>
-      <type>
-        <v>Id = string()</v>
-        <d>the repository ID</d>
-        <v>Name = string()</v>
-        <d>the type name of the alias</d>
-        <v>AliasTC = TC</v>
-        <d>the typecode for the type which the alias refer to</d>
-      </type>
-      <desc>
-        <p>Function returns the IDL typecode for alias.</p>
-      </desc>
-    </func>
-    <func>
-      <name>exception(Id, Name, ElementList) -> TC</name>
-      <fsummary>Return the exception IDL typecode</fsummary>
-      <type>
-        <v>Id = string()</v>
-        <d>the repository ID</d>
-        <v>Name = string()</v>
-        <d>the type name of the exception</d>
-        <v>ElementList = [{MemberName, TC}]</v>
-        <d>a list of the exception elements</d>
-        <v>MemberName = string()</v>
-        <d>the element name</d>
-      </type>
-      <desc>
-        <p>Function returns the IDL typecode for exception.</p>
-      </desc>
-    </func>
-    <func>
-      <name>get_tc(Object) -> TC</name>
-      <name>get_tc(Id) -> TC</name>
-      <fsummary>Fetch typecode</fsummary>
-      <type>
-        <v>Object = record()</v>
-        <d>an IDL specified struct, union or exception</d>
-        <v>Id = string()</v>
-        <d>the repository ID</d>
-      </type>
-      <desc>
-        <p>If the get_tc/1 gets a record that is and IDL specified 
-          struct, union or exception as a parameter it returns the 
-          typecode.</p>
-        <p>If the parameter is a repository ID it uses the Interface Repository
-          to get the typecode.</p>
-      </desc>
-    </func>
-    <func>
-      <name>check_tc(TC) -> boolean()</name>
-      <fsummary>Check syntax of an IDL typecode</fsummary>
-      <desc>
-        <p>Function checks the syntax of an IDL typecode.</p>
-      </desc>
-    </func>
-  </funcs>
-  
-</erlref>
-
diff --git a/lib/orber/doc/src/orbs.gif b/lib/orber/doc/src/orbs.gif
deleted file mode 100644
index 47f2c85441..0000000000
--- a/lib/orber/doc/src/orbs.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/part.xml b/lib/orber/doc/src/part.xml
deleted file mode 100644
index ef84b8c05a..0000000000
--- a/lib/orber/doc/src/part.xml
+++ /dev/null
@@ -1,49 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE part SYSTEM "part.dtd">
-
-<part xmlns:xi="http://www.w3.org/2001/XInclude">
-  <header>
-    <copyright>
-      <year>1997</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-
-    </legalnotice>
-
-    <title>Orber User's Guide</title>
-    <prepared></prepared>
-    <docno></docno>
-    <date>1998-04-26</date>
-    <rev>2.2</rev>
-  </header>
-  <description>
-    <p>The <em>Orber</em> application is an Erlang implementation of a
-      CORBA Object Request Broker.</p>
-  </description>
-  <xi:include href="ch_contents.xml"/>
-  <xi:include href="ch_introduction.xml"/>
-  <xi:include href="ch_orber_kernel.xml"/>
-  <xi:include href="ch_ifr.xml"/>
-  <xi:include href="ch_install.xml"/>
-  <xi:include href="ch_idl_to_erlang_mapping.xml"/>
-  <xi:include href="ch_naming_service.xml"/>
-  <xi:include href="ch_security.xml"/>
-  <xi:include href="ch_stubs.xml"/>
-  <xi:include href="ch_exceptions.xml"/>
-  <xi:include href="ch_interceptors.xml"/>
-  <xi:include href="ch_orberweb.xml"/>
-  <xi:include href="ch_debugging.xml"/>
-</part>
-
diff --git a/lib/orber/doc/src/ref_man.xml b/lib/orber/doc/src/ref_man.xml
deleted file mode 100644
index 6fa409538d..0000000000
--- a/lib/orber/doc/src/ref_man.xml
+++ /dev/null
@@ -1,53 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE application SYSTEM "application.dtd">
-
-<application xmlns:xi="http://www.w3.org/2001/XInclude">
-  <header>
-    <copyright>
-      <year>1997</year><year>2016</year>
-      <holder>Ericsson AB. All Rights Reserved.</holder>
-    </copyright>
-    <legalnotice>
-      Licensed under the Apache License, Version 2.0 (the "License");
-      you may not use this file except in compliance with the License.
-      You may obtain a copy of the License at
- 
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-      See the License for the specific language governing permissions and
-      limitations under the License.
-    
-    </legalnotice>
-
-    <title>Orber Reference Manual</title>
-    <prepared></prepared>
-    <docno></docno>
-    <date>1998-05-05</date>
-    <rev>2.0</rev>
-  </header>
-  <description>
-    <p>The <em>Orber</em> application is an Erlang implementation of a
-      CORBA Object Request Broker.</p>
-  </description>
-  <xi:include href="any.xml"/>
-  <xi:include href="fixed.xml"/>
-  <xi:include href="corba.xml"/>
-  <xi:include href="corba_object.xml"/>
-  <xi:include href="orber.xml"/>
-  <xi:include href="orber_ifr.xml"/>
-  <xi:include href="orber_tc.xml"/>
-  <xi:include href="orber_acl.xml"/>
-  <xi:include href="CosNaming.xml"/>
-  <xi:include href="CosNaming_NamingContext.xml"/>
-  <xi:include href="CosNaming_NamingContextExt.xml"/>
-  <xi:include href="CosNaming_BindingIterator.xml"/>
-  <xi:include href="lname.xml"/>
-  <xi:include href="lname_component.xml"/>
-  <xi:include href="Module_Interface.xml"/>
-  <xi:include href="interceptors.xml"/>
-  <xi:include href="orber_diagnostics.xml"/>
-</application>
-
diff --git a/lib/orber/doc/src/theORB.gif b/lib/orber/doc/src/theORB.gif
deleted file mode 100644
index 976672b8df..0000000000
--- a/lib/orber/doc/src/theORB.gif
+++ /dev/null
diff --git a/lib/orber/doc/src/tools_debugging_part.xml b/lib/orber/doc/src/tools_debugging_part.xml
deleted file mode 100644
index 94af44833c..0000000000
--- a/lib/orber/doc/src/tools_debugging_part.xml
+++ /dev/null
@@ -1,40 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE part SYSTEM "part.dtd">
-
-<part>
-  <header>
-    <copyright>
-      <year>2002</year>
-      <year>2016</year>
-      <holder>Ericsson AB, All Rights Reserved</holder>
-    </copyright>
-    <legalnotice>
-  Licensed under the Apache License, Version 2.0 (the "License");
-  you may not use this file except in compliance with the License.
-  You may obtain a copy of the License at
- 
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
-
-  The Initial Developer of the Original Code is Ericsson AB.
-    </legalnotice>
-
-    <title>Tools, Debugging and FAQ</title>
-    <prepared>Niclas Eklund</prepared>
-    <docno></docno>
-    <date>2002-06-25</date>
-    <rev>A</rev>
-  </header>
-  <description>
-    <p>This chapter describe the available tools and debugging facilities for Orber.
-      Also contain a FAQ listing of the most common mistakes.</p>
-  </description>
-  <include file="ch_orberweb"></include>
-  <include file="ch_debugging"></include>
-</part>
-