Utility yaz-marcdump got option to display YAZ version (-V)

[yaz-moved-to-github.git] / doc / asn.xml

diff --git a/doc/asn.xml b/doc/asn.xml
index 7f6208e..bb84b52 100644 (file)
--- a/doc/asn.xml
+++ b/doc/asn.xml
@@ -1,4 +1,3 @@
-<!-- $Id: asn.xml,v 1.19 2007-05-04 12:24:15 adam Exp $ -->
  <chapter id="asn"><title>The Z39.50 ASN.1 Module</title>
   <sect1 id="asn.introduction"><title>Introduction</title>
    <para>
@@ -132,77 +131,6 @@
     
    </para>
   </sect1>
-  <sect1 id="asn.oid"><title>Object Identifiers (YAZ 2)</title>
-
-  <note>
-   <para>
-    This material only applies to version 2 series of YAZ. You need not
-    read this material if you are working with YAZ 3. 
-    See <xref linkend="tools.oid"/> for more information on OIDs.
-   </para>
-  </note>
-
-  <para>
-    When you refer to object identifiers in your application, you need to
-    be aware that SR and Z39.50 use two different set of OIDs to refer to
-    the same objects. To handle this easily, &yaz; provides a utility module
-    to &asn; which provides an internal representation of the OIDs used in
-    both protocols. Each oid is described by a structure:
-   </para>
-   
-   <screen>
-typedef struct oident
-{
-    enum oid_proto proto;
-    enum oid_class class;
-    enum oid_value value;
-    int oidsuffix[OID_SIZE];
-    char *desc;
-} oident;
-   </screen>
-   
-   <para>
-    The <literal>proto</literal> field can be set to either
-    <literal>PROTO_SR</literal> or <literal>PROTO_Z3950</literal>.
-    The <literal>class</literal> might be, say,
-    <literal>CLASS_RECSYN</literal>, and the <literal>value</literal> might be
-    <literal>VAL_USMARC</literal> for the USMARC record format. Functions
-   </para>
-   
-   <screen>
-int *oid_ent_to_oid(struct oident *ent, int *dst);
-struct oident *oid_getentbyoid(int *o);
-   </screen>
-   
-   <para>
-    are provided to map between object identifiers and database entries.
-    If you store a member of the <literal>oid_proto</literal> type in
-    your association state information, it's a simple matter, at runtime,
-    to generate the correct OID when you need it. For decoding, you can
-    simply ignore the proto field, or if you're strict, you can verify
-    that your peer is using the OID family from the correct protocol.
-    The <literal>desc</literal> field is a short, human-readable name
-    for the PDU, useful mainly for diagnostic output.
-   </para>
-   
-   <note>
-    <para>
-     The old function <function>oid_getoidbyent</function> still exists but
-     is not thread safe. Use <function>oid_ent_to_oid</function> instead
-     and pass an array of size <literal>OID_SIZE</literal>.
-    </para>
-   </note>
-   
-   <note>
-    <para>
-     Plans are underway to merge the two protocols into a single
-     definition, with one set of object identifiers. When this happens, the
-     oid module will no longer be required to support protocol
-     independence, but it should still be useful as a simple OID database.
-    </para>
-   </note>
-  
-  </sect1>
   <sect1 id="asn.external"><title>EXTERNAL Data</title>
    
    <para>