[docs] xmldocs - docelic modified 10 files
docs at icdevgroup.org
docs at icdevgroup.org
Mon Jan 3 15:43:54 EST 2005
User: docelic
Date: 2005-01-03 20:43:54 GMT
Modified: . Makefile
Modified: glossary ITL order true
Added: files/pricing pricing.txt
Added: glossary checkout dereference profile tax
Removed: glossary deref
Log:
- Makefile: supported document 'vars'
- glossary/*: glossary entries (some big ones!)
- files/*: supporting files
Revision Changes Path
1.52 +1 -1 xmldocs/Makefile
rev 1.52, prev_rev 1.51
Index: Makefile
===================================================================
RCS file: /var/cvs/xmldocs/Makefile,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -r1.51 -r1.52
--- Makefile 8 Dec 2004 12:39:58 -0000 1.51
+++ Makefile 3 Jan 2005 20:43:54 -0000 1.52
@@ -12,7 +12,7 @@
#############################################################
# Base definitions
-SYMBOL_TYPES= pragmas globvars tags confs filters catvars
+SYMBOL_TYPES= pragmas vars tags confs filters
GUIDES = iccattut xmldocs
HOWTOS = howtos
GLOSSARY = glossary
1.1 xmldocs/files/pricing/pricing.txt
rev 1.1, prev_rev 1.0
Index: pricing.txt
===================================================================
code common q1 q5 q10 XL S red
99-102 10 9 8 1 -0.50 0.75
00-343 2
red 0.75
1.6 +2 -2 xmldocs/glossary/ITL
rev 1.6, prev_rev 1.5
Index: ITL
===================================================================
RCS file: /var/cvs/xmldocs/glossary/ITL,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ITL 27 Dec 2004 01:06:11 -0000 1.5
+++ ITL 3 Jan 2005 20:43:54 -0000 1.6
@@ -248,7 +248,7 @@
<section>
-<title>Deeper look at argument quoting</title>
+<title>Deeper Look at Argument Quoting</title>
<para>
The question is — exactly when can you omit the quotes around
@@ -479,7 +479,7 @@
<section>
-<title>Perl calls</title>
+<title>Perl Calls</title>
<para>
You can simply ignore this section if you don't know the &PERL;
1.2 +2 -2 xmldocs/glossary/order
rev 1.2, prev_rev 1.1
Index: order
===================================================================
RCS file: /var/cvs/xmldocs/glossary/order,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- order 27 Dec 2004 01:06:11 -0000 1.1
+++ order 3 Jan 2005 20:43:54 -0000 1.2
@@ -96,7 +96,7 @@
</para>
<section>
- <title>Link-based ordering</title>
+ <title>Link-based Ordering</title>
<para>
Link-based ordering is implemented through the &tag-order; tag. You should
@@ -144,7 +144,7 @@
</section>
<section>
- <title>Form-based ordering</title>
+ <title>Form-based Ordering</title>
<para>
Form-based ordering comes handy when you want to implement more complex
1.5 +2 -3 xmldocs/glossary/true
rev 1.5, prev_rev 1.4
Index: true
===================================================================
RCS file: /var/cvs/xmldocs/glossary/true,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- true 15 Dec 2004 14:24:00 -0000 1.4
+++ true 3 Jan 2005 20:43:54 -0000 1.5
@@ -1,6 +1,5 @@
In general programming terms, a <emphasis>true</emphasis> value is
-anything, except <literal>0</literal> (zero), <literal>""</literal>
-(an empty string) and undefined value.
+anything that is not &glos-false;.
</para><para>
-Note that a value of a string containing only whitespace
+Note that a string containing only whitespace
(say, one TAB or space) is also considered 'true'.
1.1 xmldocs/glossary/checkout
rev 1.1, prev_rev 1.0
Index: checkout
===================================================================
The check-out process consists of users filling in information via &glos-HTML;
forms, and &IC; verifying their input on arbitrary number of levels using
so-called <emphasis>profiles</emphasis>.
</para>
<para>
Profiles can be defined in external files (and activated using
&conf-OrderProfile;) or in &glos-scratch; variables. External files are,
by convention, kept in <filename class='directory'>CATROOT/etc/</filename> and
begin with <literal>profiles.</literal>. Multiple profiles
can be defined in each file.
</para>
<para>
You can learn about the principle and syntax of the profile files in the
&glos-profile; glossary entry.
Only when the input "passes" the profile check, is the check-out process
able to proceed.
</para>
<section id="SimpleOrderReportFile">
<title>Simple Order Report File</title>
<para>
Most of the time, you will want the successful check-out operation (order
completion) to generate some kind of notification. In most common setups,
this will include e-mailing order reports.
</para>
<para>
Simple order report file, <filename>CATROOT/etc/report</filename>, defines
the layout (template) of the order report. All form variables are accessible
from the report file by using the familiar &PERL; <literal>$</literal> syntax.
<programlisting><![CDATA[
Order Date: $date
Name: $name
Email address: $email
Shipping address: $addr
Town, State, Zip: $town, $state $zip
Country: $country
]]></programlisting>
<!-- TODO what's the mental line for this?
Interchange defines some values for use in the search form - they begin
with <literal>mv_</literal> and are automatically ignored.
The order number as set by backend ordering is in the variable mv_order_number,
and available for your use.
-->
</para>
</section>
<section id="FullyConfigurableOrderReports">
<title>Fully-configurable Order Reports</title>
<para>
You can specify fully-configurable order reports by setting the hidden
form variable <mv>mv_order_report</mv> to an existing &IC; catalog page.
This page will be processed (interpolated and all) as standard Interchange
page before being sent by email. That said,
you see you could include &glos-HTML; in the file. Although many mail clients
<emphasis>will</emphasis> parse HTML, it seems that the initial excitement
among the ordinary people vanished and they
again prefer plain-text e-mails. If you wanted to provide a &glos-HTML;
version, you could always provide a link to a copy on your web server.
<!-- TODO copy example to files/ and create link
An example report is provided in the demo file
<filename>pages/ord/report.html</filename>.
-->
</para>
</section>
<!-- TODO work on this
<section id="OrderReceipts">
<title>Order Receipts</title>
<para>
The file can of course be configured with all Interchange tags, and
will be interpolated for the ordered items before they are deleted from
the user session. You can set the default receipt with the <literal>receipt</literal>
key in SpecialPage. If using order <emphasis>Route</emphasis>s, as in the <literal>foundation</literal> demo,
you set it with the <literal>receipt</literal> key to <literal>Route</literal>.
</para>
</section>
-->
<section id="OrderCounter">
<title>Order Counter</title>
<para>
An order counter can be enabled simply — just set the &conf-OrderCounter;
directive to the appropriate file name.
An incrementing count of all orders will be
kept and assigned as orders are placed. By default, the number
starts at <literal>0</literal>, but you can edit the file and change the
starting or current number at any time.
This feature is made possible by the <classname>File::CounterFile</classname>
&PERL; module.
</para>
</section>
<section id="CustomerFormFields">
<title>Custom Form Fields</title>
<para>
The default basket and order pages contain a number of form fields,
allowing customers to enter the necessary information. This, however, can't
satisfy all individual needs. To remove some of the fields, simply delete
them from the &glos-HTML; pages (or, better yet, disable by using the
&tag-comment; tag). Do not forget to also deactivate any entries in
the profile files.
</para>
<para>
<!-- TODO does this work for order.html only or basket.html too ? -->
To add new fields, simply add them to the pages. The information will
automatically be included in the report files. Here's a template you
could re-use for your own fields, replacing <literal>town</literal>
with your values:
<!-- TODO is <input> arg maxlen= or maxlength= ? -->
<programlisting><![CDATA[
<input type="text" name="town" value="[value town]" size="30" maxlen="40" />
]]></programlisting>
</para>
<note>
<para>
Using <literal>maxlen</literal> &glos-HTML; <input> attribute to
limit the length of incoming
input is insecure, since that check is performed client-side only.
It is surely an element of good programming on all levels, but don't forget
to perform real length check in the appropriate form profile.
<!-- TODO link to glos-profile-->
</para>
</note>
<!-- This is obvious, isn't it?
Choose a name for this input field such as "email" for an email
address. Set the name attribute to the name you have chosen.
The value attribute specifies the default value to give the field when
the page is displayed. Because the customer may enter information on
the order page, return to browsing, and come back to the order page,
you want the default value to be what was entered the first time. This
is done with the <code>[value var]</code> element, which returns the last value of an
input field. Thus,
<programlisting><![CDATA[
value="[value name]"
]]></programlisting>
will evaluate to the name entered on the previous order screen, such
as:
<programlisting><![CDATA[
value="Jane Smith"
]]></programlisting>
which will be displayed by the browser.
The size attributes specifies how many characters wide the input field
should be on the browser. You do not need to set this to fit the
longest possible value since the browser will scroll the field, but
you should set it large enough to be comfortable for the customer.
-->
</section>
<para>
1.1 xmldocs/glossary/dereference
rev 1.1, prev_rev 1.0
Index: dereference
===================================================================
<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).
With copy by value, 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 case of copy by reference, 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.
In other words, the data is not duplicated, only the access points are.
1.1 xmldocs/glossary/profile
rev 1.1, prev_rev 1.0
Index: profile
===================================================================
&IC; form <emphasis>profiles</emphasis> are used to validate form inputs and
eventually trigger additional actions. Input fields validation usually contains
of requireing some of the fields to be non-empty or match a specific regular
expression pattern at time of submit.
</para>
<para>
Actions, for example, can be used to signalize the completion of an order
process. Profiles are not specific to order checkout or something; they are
an integral part of all form processing in &IC;. You will also see actions
such as &IC; account creation, login, logout or password change being at least
partly handled using profiles.
</para>
<para>
Profiles can be defined in external files (and activated using
&conf-OrderProfile;) or in &glos-scratch; variables. External files are,
by convention, kept in <filename class='directory'>CATROOT/etc/</filename> and
begin with <literal>profiles.</literal>. Multiple profiles
can be defined in each file.
</para>
<para>
<!-- TODO move profiles description to separate file -->
A very simple &glos-hello-world;-like profile example follows:
<programlisting>
__NAME__ test_profile
fname=required
lname=required
__END__
</programlisting>
The above profile requires customers' first and last names to be
entered.
</para>
<note>
<para>
The <literal>__NAME__</literal> and <literal>__END__</literal> markers
must start at the beginning of line, not even whitespace is allowed. This
is very important because the profile would be ignored otherwise.
</para>
</note>
<para>
If users leave some of the required fields empty (or there's some other
reason why you'd want them to correct their input), you'll probably want
to show them the form page again and display some kind of an error
message. To override the default messages, simply specify your own strings
after the format check specification. Here's an example:
<programlisting>
__NAME__ test_profile
fname=required First name is required!
lname=required Last name is required!
__END__
</programlisting>
</para>
<section>
<title>Format-check Specification</title>
<para>
>From the examples above, you can see that the format check specifications are
specified as <literal><replaceable>FORM_VARIABLE_NAME</replaceable>=<replaceable>CHECK_TYPE</replaceable></literal>. Form variable names are obvious; in our
example they were <literal>fname</literal> and <literal>lname</literal>.
Check types, however, can take on one of the following values:
</para>
<itemizedlist>
<listitem><para>
<literal>required</literal> - form field must end up with non-empty content.
If no direct &glos-CGI; variable exists, variable is searched in the
the &glos-value;s space (form fields submitted at some past time during
the session) and &glos-UserDB;
</para></listitem>
<listitem><para>
<literal>mandatory</literal> - form field must contain a non-blank value,
and it must
exist directly on the form being checked. In other words, it must be
a &glos-CGI; variable and not a &glos-value; variable coming from some
previous form input or &glos-UserDB;
</para></listitem>
<listitem><para>
<!-- TODO exactly what regex is allowed for 'phone' type? -->
<literal>phone</literal> - form field must look like a phone number
(by a very loose specification), allowing numbers from all countries
</para></listitem>
<listitem><para>
<literal>phone_us</literal> - form field must have US phone number
formatting with area code included
</para></listitem>
<listitem><para>
<!-- TODO is state checked in state DB or what ? -->
<literal>state</literal> - form field must contain an US state,
including DC and Puerto Rico
</para></listitem>
<listitem><para>
<!-- TODO is province checked in state DB or what ? and same for
other options below -->
<literal>province</literal> - form field must contain a canadian
province or pre-1997 territory
</para></listitem>
<listitem><para>
<literal>state_province</literal> - form field must contain an US state
or canadian province
</para></listitem>
<listitem><para>
<literal>zip</literal> - form field must contain
an US postal code formatting, with optional ZIP+4.
This is also called by the alias <literal>us_postcode</literal>
</para></listitem>
<listitem><para>
<literal>ca_postcode</literal> - form field must contain a canadian
postal code formatting (check for a valid first letter is performed)
</para></listitem>
<listitem><para>
<literal>postcode</literal> - form field must contain a valid
US or Canada postal code formatting
</para></listitem>
<listitem><para>
<literal>true</literal> - form field content must begin with
<literal>y</literal>, <literal>1</literal> or <literal>t</literal>
(case-<emphasis>insensitive</emphasis>)
</para></listitem>
<listitem><para>
<literal>false</literal> - form field content must begin with
<literal>n</literal>, <literal>0</literal> or <literal>f</literal>
(case-<emphasis>insensitive</emphasis>)
</para></listitem>
<listitem><para>
<literal>email</literal> - form field content must pass rudimentary
e-mail address check; it must contain "AT"
(<literal>@</literal>), a name, and a minimal domain
</para></listitem>
<listitem><para>
<literal>regex <replaceable>REGEX_PATTERNs</replaceable></literal> -
form field content must match regular
<!-- TODO whitespace or space? -->
expression patterns. Multiple patterns can be specified, separated by
whitespace
</para></listitem>
<listitem><para>
<literal>length <replaceable>RANGE</replaceable></literal>
<!-- TODO can it be 4,8? -->
- form field content must satisfy the allowed length range
</para></listitem>
<listitem><para>
<literal>unique <replaceable>DATABASE</replaceable></literal>
- form field content must not exist in a given DATABASE.
</para></listitem>
<listitem><para>
<literal>filter <replaceable>FILTER</replaceable></literal>
- form field content should be equal to the original value after
being ran through the specified FILTER
</para></listitem>
</itemizedlist>
</section>
<para>
1.1 xmldocs/glossary/tax
rev 1.1, prev_rev 1.0
Index: tax
===================================================================
Interchange allows taxing in a number of ways.
<!-- TO what price is taxing applied, and how it's available ? price
without and with tax included, for each product and total? -->
</para>
<!-- TODO what about that racke's TaxInclusive or what? -->
<section>
<title>Simple "salestax.asc" Method</title>
<para>
In this simple taxing method, &conf-SalesTax; directive is
set to form fields whose values will be used as keys to look up
the tax rate in <filename>CATROOT/products/salestax.asc</filename>.
</para>
<para>
Sales tax calculation in this simple scheme is performed on a straight
percentage basis,
with certain items allowed to be tax-exempt. Simply initialize the
&conf-SalesTax; directive to the name of lookup fields. Those lookup fields
are the ones that are available on the final order form and indicate
geographical locality. Usually, the fields are zip and state codes:
<programlisting><![CDATA[
SalesTax zip,state
]]></programlisting>
Each line of the mentioned <filename>CATROOT/products/salestax.asc</filename>
file should contain a code (again, usually 5-digit zip or 2-letter state
ID), followed by a TAB character and a desired percentage.
<programlisting><![CDATA[
default 0.0
45056 .0525
61821 .0725
61801 .075
IL .0625
OH .0525
VAT .15
WA .08
]]></programlisting>
<!-- TODO salestax.asc - lookup by many values.. they get added together
or first or last takes precendence -->
Based on user information given on the order form (and given our
sample &conf-SalesTax; setting), &IC; will attempt a tax lookup by
zip and state (in that order), and apply the percentage found to the
<emphasis>subtotal</emphasis> of the order.
<!-- TODO subtotal is without taxing or not? (you can always see the
price without taxing applied by calling &tag-subtotal;). -->
<!-- TODO comment this - is subtotal plain, and [salestax] only salestax
or what? -->
The subtotal will include item prices, taxes and shipping costs (if
&conf-TaxShipping; was set up).
It will add the percentage, then make that available with the &tag-salestax;
tag for display on the order form.
If no match is found in <filename>CATROOT/products/salestax.asc</filename>,
the entry <literal>DEFAULT</literal> (case-<emphasis>insensitive</emphasis>)
will be applied — which is usually <emphasis>zero</emphasis>.
</para>
<!--
If business is being done on a national basis, it is now common to have
to collect sales tax for multiple states. If you are doing so, it is possible
to subscribe to a service which issues regular updates of the sales tax
percentages - usually by quarterly or monthly subscription. Such a
database should be easily converted to Interchange format - but some systems
are rather convoluted, and it will be well to check and see if the
program can export to a flat ASCII file format based on zip code.
-->
<para>
If some items are not taxable, then you must set up a field in your
database which indicates that. Announce this field name by using the
&conf-NonTaxableField; directive. If the specifield field for that item
evaluates to a &glos-true; value, sales tax will not be applied to the item.
</para>
<!--
If your state taxes shipping, use the <emphasis>TaxShipping</emphasis>
directive. Utah and Nevada are known to tax shipping - there may be others.
-->
<para>
If you want to set a fixed tax for all orders, as might occur for VAT
in some countries, then &conf-SalesTax; set to the zip or state codes is
not optimal for the purpose of sales tax calculation. The solution is to
introduce an arbitrary variable that, unlike
<database class='field'>zip</database> or
<database class='field'>state</database>, does not change from user to user.
Then, you would set that variable in user session to point to a fixed entry
in the
<filename>CATROOT/products/salestax.asc</filename> file.
Exactly how you're going to set a session variable is not important;
you could use the &conf-ValuesDefault; directive (
<code>ValuesDefault tax_code VAT</code>), a hidden form variable
(<code><![CDATA[<input type="hidden" name="tax_code" value="VAT" />]]></code>),
or a simple &PERL; code block
(<code><![CDATA[[perl] $Values->{tax_code} = 'VAT'; return [/perl]]]></code>).
</para>
</section>
<section>
<title>"Fly Tax" Method</title>
<para>
This is one of the simpler taxing methods as well. A series of Interchange
&conf-Variable; settings are read to develop a salestax rate for one or more
geographical localities.
</para>
<para>
With this method, you implement the simple SalesTax method explained above,
but only put one entry in
<filename>CATROOT/products/salestax.asc</filename>. Then
&var-TAXAREA;, &var-TAXRATE;
and &var-TAXSHIPPING; catalog variables would be used to build
the tax rates.
</para>
<para>
The single entry in <filename>CATROOT/products/salestax.asc</filename>
should be default with a value of &tag-fly-tax;:
<programlisting>
DEFAULT [fly-tax]
</programlisting>
<!--
To set the field that is used for the state code, you use the
standard Interchange {{CMD[jump="icconfig.html#SalesTax"]SalesTax}} directive. It would almost always
be set to <literal>state</literal>.
-->
</para>
</section>
<section>
<title>"Salestax Multi" or "VAT Taxing" Method</title>
<para>
With this method, <database>country</database> and <database>state</database>
databases are used to develop complex VAT or salestax rate calculations,
based on country and state, possibly with different rates based on product
type.
</para>
<para>
The &conf-SalesTax; directive must be set to <literal>multi</literal>, and
then the type of tax to apply will be read from the
<database>country</database> database. Since this is a standard database, to
display taxing for say, Croatia (code <literal>HR</literal>), you'd
simply call:
<programlisting>
[data table=country col=tax key=HR]
</programlisting>
We've mentioned some hard-coded values above (the country table, column names
etc.), but this is all configurable using
&var-MV_COUNTRY_TABLE;,
&var-MV_COUNTRY_FIELD;,
&var-MV_COUNTRY_TAX_FIELD;,
&var-MV_STATE_TABLE;,
&var-MV_STATE_FIELD;,
&var-MV_STATE_TAX_FIELD;,
&var-MV_TAX_TYPE_FIELD; and
&var-MV_TAX_CATEGORY_FIELD; variables.
</para>
<para>
So, with this <emphasis>multi</emphasis> approach, &IC; first performs a lookup
in the <database>country</database> database. The default key for the lookup
is, of course, <code>[value country]</code> (value of the
<literal>country</literal> form variable), and the column retrieved is
<database class='field'>tax</database>. At that point, the following rules
are applied:
<itemizedlist>
<listitem><para>
If no string is found, tax returns <literal>0</literal>
</para></listitem>
<listitem><para>
If string <literal>simple:<replaceable>COUNTRY_CODE</replaceable></literal>
is found, &tag-fly-tax; is used for the appropriate country.
</para></listitem>
<listitem><para>
If string <literal>state</literal> is found, then another lookup
in the <database>country</database> databaseis done; it's something along
the lines of
<programlisting>
select tax from state where country = [value country] and state = [value state]
</programlisting>
The value is then applied as explained in the following steps
</para></listitem>
<listitem><para>
If a pure (integer or decimal) number is found (such as
<literal>0.05</literal>), the rate is applied directly
</para></listitem>
<listitem><para>
If a percentage is found, such as <literal>22.2%</literal>, the rate is,
obviously, applied as a percentage
</para></listitem>
<listitem><para>
<!-- is default= necessary, or just allowed to be specified? -->
If a string <literal>category = <replaceable>D</replaceable>%, default = <replaceable>D</replaceable>%</literal> is found, the
<database class='field'>tax_category</database> field in the
<database>products</database> database is used to determine tax rate.
(The default option is there to be applied if the
<database class='field'>tax_category</database> for a product is zero
or unspecified.)
</para></listitem>
</itemizedlist>
<!-- Move to appropriate tag's examples
This product data
!block example
sku price tax_category
os28003 10.00 tools
os28004 20.00 food
!endblock
with this country and state data:
!block example
code name tax
US U.S.A. state
JP Japan tools=10%, default=15%
code country state name tax
0001 US IL Illinois 6.5%
0002 US OH Ohio default = 5.5%, food = 1%
0003 US AZ Arizona
!endblock
Will yield tax for one each of os28003 and os28004 of:
!block example
Japan $4.00
US/IL $1.95
US/OH $0.75
US/AZ $0.00
!endblock
-->
</para>
</section>
<section>
<title>"Levies" or "Multiple Tax" Method</title>
<para>
Using &conf-Levies; and &conf-Levy; structure, any or all of
the above methods are used in combination to implement the a
taxing scheme of truly arbitrary complexity.
</para>
<!-- TODO missing info on levies -->
<!-- TODO where does "Levy" come from? -->
</section>
<para>
More information about the docs
mailing list