Minor fixes, especially in the beginning
[idzebra-moved-to-github.git] / doc / recordmodel.xml
index 0eb13de..660c95e 100644 (file)
@@ -1,5 +1,5 @@
 <chapter id="record-model">
 <chapter id="record-model">
- <!-- $Id: recordmodel.xml,v 1.2 2002-04-09 19:20:23 adam Exp $ -->
+ <!-- $Id: recordmodel.xml,v 1.3 2002-04-10 14:47:49 heikki Exp $ -->
  <title>The Record Model</title>
  
  <para>
  <title>The Record Model</title>
  
  <para>
@@ -18,6 +18,8 @@
   structured
   record type <literal>grs</literal> as introduced in
   <xref linkend="record-types"/>.
   structured
   record type <literal>grs</literal> as introduced in
   <xref linkend="record-types"/>.
+  FIXME - Need to describe the simple string-tag model, or at least 
+          refer to it here. -H
  </para>
 
  <para>
  </para>
 
  <para>
 
    <note>
     <para>
 
    <note>
     <para>
-     Documentation needs extension here about types of nodes - numerical,
+     FIXME! Documentation needs extension here about types of nodes - numerical,
      textual, etc., plus the various types of inclusion notes.
     </para>
    </note>
      textual, etc., plus the various types of inclusion notes.
     </para>
    </note>
    </para>
 
    <para>
    </para>
 
    <para>
+    FIXME - Need a diagram here, or a simple explanation how it all hangs together -H
+   </para>
+
+   <para>
 
     <itemizedlist>
      <listitem>
 
     <itemizedlist>
      <listitem>
    </para>
 
    <para>
    </para>
 
    <para>
-    <emphasis>NOTE: The schema-mapping functions are so far limited to a
+    <emphasis>NOTE: FIXME! The schema-mapping functions are so far limited to a
      straightforward mapping of elements. This should be extended with
      mechanisms for conversions of the element contents, and conditional
      mappings of elements based on the record contents.</emphasis>
      straightforward mapping of elements. This should be extended with
      mechanisms for conversions of the element contents, and conditional
      mappings of elements based on the record contents.</emphasis>
    </para>
 
    <para>
    </para>
 
    <para>
-    <emphasis>NOTE: This will be described better. We're in the process of
+    <emphasis>NOTE: FIXME! This will be described better. We're in the process of
      re-evaluating and most likely changing the way that MARC records are
      handled by the system.</emphasis>
    </para>
      re-evaluating and most likely changing the way that MARC records are
      handled by the system.</emphasis>
    </para>
       is used to show the hierarchical structure of the record. All
       "GRS" type records support both the GRS-1 and SUTRS
       representations.
       is used to show the hierarchical structure of the record. All
       "GRS" type records support both the GRS-1 and SUTRS
       representations.
+      FIXME - What is SUTRS - should be expanded here
      </para>
     </listitem>
 
      </para>
     </listitem>
 
       abstract syntaxes can be mapped to the SOIF format, although nested
       elements are represented by concatenation of the tag names at each
       level.
       abstract syntaxes can be mapped to the SOIF format, although nested
       elements are represented by concatenation of the tag names at each
       level.
+      FIXME - Is this used anywhere ? What is SOIF anyway? -H
      </para>
     </listitem>
 
      </para>
     </listitem>