[docs] xmldocs - docelic modified 5 files

[docs at icdevgroup.org]

User:      docelic
Date:      2004-09-26 19:49:23 GMT
Modified:  glossary pragma
Added:     glossary dereferencing ic-tag-lang namespace scratch-var
Log:
- Modified and new glossary entries

Revision  Changes    Path
1.2       +3 -1      xmldocs/glossary/pragma


rev 1.2, prev_rev 1.1
Index: pragma
===================================================================
RCS file: /var/cvs/xmldocs/glossary/pragma,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- pragma	21 Sep 2004 16:19:46 -0000	1.1
+++ pragma	26 Sep 2004 19:49:23 -0000	1.2
@@ -7,8 +7,10 @@
 
 <glossdef>
 <para>
-Pragmas are used to control various aspects of page and data parsing and display. Values can be defined catalog-wide, page-wide and ITL-block wide.
+Pragmas are used to control various aspects of page and data parsing and display. They are processed before an Interchange page goes to the normal processing
+routine.
 </para><para>
+Pragma values can be defined catalog-wide, page-wide and ITL-block wide.
 To define a pragma catalog-wide, use the <option>Pragma</option> directive:
 <cmdsynopsis>Pragma NAME <group choice='req'><arg choice='plain'>0</arg><arg choice='plain'>1</arg><arg choice='plain'>=<replaceable>pragma-specific value</replaceable></arg></group>
 </cmdsynopsis>



1.1                  xmldocs/glossary/dereferencing


rev 1.1, prev_rev 1.0
Index: dereferencing
===================================================================

<glossentry id="deref">
<glossterm>Dereferencing</glossterm>

<glossdef>
<para>
<emphasis>Dereferencing</emphasis> is strictly a computer-programming
issue, but we will try to explain it in very brief and comprehensible terms,
so that you understand the idea of <firstterm>dereferencing</firstterm> and
its practical effect when data structures are copied.
</para><para>
Let's say we want to compose a list of a few automobiles. Each entry 
in the list will contain the fields
<database class='field'>model</database>,
<database class='field'>year</database> and
<database class='field'>mileage</database>.
</para><para>
Theoretically speaking, to solve this real-world problem with the help of a
computer, we would create a template (containing the three fields), and
produce one <emphasis>instance</emphasis> of the template for each car
we add to our list. (How this list is created, how the elements are added
and how they relate to each other is irrelevant here).
</para><para>
One imaginary list with three instances could be visually represented
in the following way:
</para>
<programlisting>
             Model     Year  Mileage
  list[0] { 'Fiat',    1996, 177940 }
  list[1] { 'Citroen', 2001, 66000  }
  list[2] { 'Citroen', 2002, 23000  }
</programlisting>

<para>
There is only one copy of this list in computer memory, and we read or modify
the elements by obtaining <firstterm>references</firstterm>
(or, <firstterm>pointers</firstterm>) to appropriate entries.
</para><para>
If we take <literal>list</literal> above to contain the list of references
to the entries, we can 
use <literal>list[0].Model</literal> to retrieve the value "Fiat", or
<literal>list[2].Year</literal> to retrieve "2002". For both of those fields,
a reference was first <emphasis>dereferenced</emphasis> (or,
<emphasis>followed</emphasis>) to reach the actual data fields.
</para><para>
When list elements need to be copied to another location (usually as part of
some bigger plan which, again, we are not interested in), they can be copied
<emphasis>by value</emphasis> (with dereferencing) or
<emphasis>by reference</emphasis> (obviously, without dereferencing).
In former case, you would end up with 2 references and 2 different
lists (initially they would be the same but afterwards you could modify
each with no connection to the other). In the latter case, you would again
have 2 references, but both pointing to the same list. Modifying data through
any of the two references would have impact on both.
</para><para>
So, when a data structure (or its element) is said to be copied
<emphasis>without dereferencing</emphasis>, then in case it was a reference,
it is still copied in itself, but all copies point to the same location.
</para>

</glossdef>

</glossentry>




1.1                  xmldocs/glossary/ic-tag-lang


rev 1.1, prev_rev 1.0
Index: ic-tag-lang
===================================================================

<glossentry id="itl">
<glossterm>ITL</glossterm>
<glossterm>Interchange Tag Language</glossterm>

<!--<acronym></acronym>-->
<!--<abbrev></abbrev>-->

<glossdef>
<para>
meek.
</para>

</glossdef>

</glossentry>




1.1                  xmldocs/glossary/namespace


rev 1.1, prev_rev 1.0
Index: namespace
===================================================================

<glossentry id="namespace">
<glossterm>Namespace</glossterm>

<glossdef>
<para>
Name-space is an abstract group of elements. Within the group, element names
must be unique, but elements of the same name can appear in different 
namespaces (so, in different groups). They are completely separate and in
no relation to each other (other than logical).
</para><para>
Generally speaking, 
the namespace indicator can be prefixed to the element name (such as
<literal>xsl:stylesheet</literal>), given as a separate parameter
(such as <literal>name="stylesheet" space="xsl"</literal>), or set
in a separate call and later considered implicit.
</para>
</glossdef>

</glossentry>




1.1                  xmldocs/glossary/scratch-var


rev 1.1, prev_rev 1.0
Index: scratch-var
===================================================================

<glossentry id="scratch-var">
<glossterm>Scratch variables</glossterm>
<glossterm>Scratch space</glossterm>
<glossterm>Scratchpad</glossterm>

<!--<acronym></acronym>-->
<!--<abbrev></abbrev>-->

<glossdef>
<para>
To each new visitor, Interchange assigns an unique
<firstterm>session ID</firstterm> and (among other things) creates a
<firstterm>scratch space</firstterm> (also referred to as 
the <emphasis>scratchpad</emphasis>) to hold various variables
which are valid throughout the session.
</para>
<para>
Once defined, a scratch variable will exist either until it is explicitly
deleted, or the session terminates.
</para>
<para>
The catalog programmer has complete control over the scratch variables.
The following tags manipulate the scratch space:
<tag>set</tag>,
<tag>seti</tag>,
<tag>tmp</tag>,
<tag>tmpn</tag>,
<tag>scratch</tag>,
<tag>scratchd</tag>,
</para>
<para>
Scratch variables are also used in form processing. See the 
<tag>button</tag> tag for examples.
</para>

</glossdef>

</glossentry>