\documentclass[11pt,epsf,a4wide]{article}
\usepackage{latexsym, amssymb, amsfonts}
\usepackage{graphicx}

\addtolength{\topmargin}{-1.7cm}
\addtolength{\oddsidemargin}{-1.5cm}
\addtolength{\evensidemargin}{-1.5cm}
\addtolength{\textwidth}{3cm}
\addtolength{\textheight}{3.4cm}

\def\mowgli{{\sc MoWGLI}}

\title{A complex use case for XML-technology:\\
\small{The European Project IST-2001-33562 MoWGLI}}
\date{}
\author{}

\begin{document}
\maketitle

\thispagestyle{empty}

\begin{abstract}
The following paper contains the results of an extensive validation
of XML-technology conducted during the last three years in the framework
of the European Project IST-2001-33562 \mowgli. 
\end{abstract}

\section{Introduction}
The European Project IST-2001-33562 \mowgli, activated in march 2002 and
lasting three years, aimed at the exploitation of semantic based 
techniques for mathematical knowledge management\cite{mkm03,mkm04}, 
with particular
emphasis on {\em web publishing}, {\em transformation} and {\em 
searching and retrieving} issues. \mowgli was based on an 
extensive use of XML-technology, aiming both at providing a
major XML test-bench and at becoming an example of best-practice in its
use. 

To grasp the dimension of the validation, we managed a 
repository of $tot$ fully structured xml-documents\footnote{Each document is
piece of formal mathematics (a definition or a theorem), exported
from the library of a well-known tool for the automatic support to formal
reasoning: the Coq proof assistant} of very different sizes,
spanning from very few elements to $tot$ gigabytes (for a total of
$tot$ gigabytes). We wrote 13951 lines of XSLT (39 stylesheets) 
plus $13398$ additional lines ($21$ stylesheets) which are 
{\em automatically generated} 
starting from a very high-level
xml description of mathematical notation\footnote{We also reused 
a stylesheet transforming MathML content to
MathML presentation (4007 lines) developed at \dots.}. Each document
in the repository has an associated RDF file mostly modeling, in addition
to traditional Dublin-Core metadata, dependendy relations among the
objects in the repository. This kind of metadata are automatically 
computed from the structured description of the object, and extensively
used to improve both searching and browsing functionality (e.g. providing
graphical descriptions of the dependency relations among the object in
the repository).

A lot of different tools have been tested during the development of
the project covering most aspects of XML-technology.
Our validation effort provided valuable feedback to many developers
of these tools,  both in the form of bug reports (abbiamo idea di quanti
bug reports abbiamo redatto e della loro classificazionI? quanti cioe'
gravi?) and suggestions for improvement (especially in performance).

We also actively contributed to software development. In particular,
let us mention the implementation of Gdome2 \cite{Gdome2}, a level2 
compliant DOM api written in C++ for the gnome programming environment, 
that was mostly developed and tuned within the framework of the 
\mowgli project, and GtkMathView (\cite{}), a rendering widget for 
MathML.

Summing up, \mowgli has been a very intense project, explicitly aimed 
to {\em stress} XML-technology up to its very limit (and possibly a 
little beyond, as in the case of stylesheets). The following paper
is just a report of our experience. 

Cenni sulla struttura del paper? Vediamo alla fine.


\section{The repository}
The aim of \mowgli was to test the feasibility of passing from a machine
readable to a machine understandable encoding of mathematical information, 
and to explore the the new potentialities offered by such 
encoding.
To this aim, we needed large collections of documents enriched with 
semantic markup, and the natural solution was to use one of the many
interesting libraries of formalized mathematics already existent in
the world; in particular, we used the library of the Coq Proof assistant, 
developed at INRIA Future. 
This gave us a pretty large ($tot$) repository of {\em fully structured} 
mathematical documents: the actual dtd contains {\em no textual elements 
at all}. As a matter of fact, text is the most typical example of 
information which is machine-readable but not machine understandable. 
By banishing text, we intentionally adopted (here, as in many other 
aspects of our project) an {\extreme} position, not as a phisolophical 
choice or commitment, but as a mere working hypothesis.

The actual details of the DTD are not so relevant here. Let us just say
that we had essentially two main classes of documents, characterized by
the different nesting depth of the markup: {\b proof objects} 
(usually quite deep) and the corresponding {\b intermediate goals} 
(relatively flat, being collections of formulas). 
 
Anticipare il perche' dell'enfasi sulla profondita', se (come
pensiamo) il comportamento risutla essere sensibile a questo
fattore. Se non lo e', cassiamo direttamente il discorso 
profondita' (o semplicemnte diciamo che non sembra essere rilevante).

Adesso mettiamo un po' di dati sulla libreria dimensione minima, 
media max dei files,
idem per profondita' e larghezza. 

Cenni sul DTD? Spiegare se/perche' non abbiamo mai sentito bisogno
di una schema? 



\begin{thebibliography}{}
\bibitem{mkm03}A.Asperti, B.Buchberger, J.Davenport (eds). 
Proceedings of the Second International Conference on Mathematical
Knowledge Management, MKM 2003. Bertinoro, Italy. LNCS, 2594.
\bibitem{mkm04}A.Asperti, G.Bancerek, A.Trybulec (eds). 
Proceeding of the Third International Conference on
Mathematical Knowledge Management, MKM 2004. Bialowieza, Poland. LNCS 3119.
\bibitem{Gdome2} P. Casarini, L.Padovani. The Gnome DOM Engine. 
Markup Languages: Theory \& Practice, Vol. 3, Issue 2, pp. 173--190, 
ISSN 1099-6621, MIT Press, April 2002. 
\end{thebibliography}


\end{document}