<STRONG>WARNING!</STRONG> Very early draft. It's only a bunch of references,
it needs work to make sense .. but anyway it is food for thought.
<!--Well, this really is <STRONG>TUNES vs the WWW</STRONG> and-->
This is <STRONG>not</STRONG> intended to be "<em>politically correct</em>"
or even only "<em>balanced</em>" and it is my (_(Mad70)) particular point of view,
<STRONG>not necessarly endorsed</STRONG> by other members and _(contributor)s
of _(TUNES), so beware.
<BR><SPAN CLASS="comment">[Also note that my English prose is horrible,
feel free to improve it].</SPAN>

See also
_(Tunes Distributed Publishing
| http://tunes.org/new/Interfaces/tunesvswww.html) by _(fare)(?).

<H4>Some technologies predating the Web that W3C is trying to reinvent (badly):</H4>

See this small article by Tim Bradshaw:
_("The wheel of reinvention" | http://www.tfeb.org/texts/wheel-of-reinvention.html).

From less formalized/near the _(user) to more formalized theories/technologies:
<UL>
  <!--LI></LI-->
  <LI>Knowledge Management/Artificial Intelligence (KM/_(AI))
    <BR>See by Jorn Barger:
      _("\"All marked up and nowhere to go\" -- XML confronts the AI Problem"
       | http://www.robotwisdom.com/ai/xml.html).
  </LI>
  <LI><SPAN CLASS="comment">[Groupware/Workflow Management? (links?)]</SPAN>.</LI>
  <LI>Information Retrieval (IR)
    <BR>See by Marcia J. Bates:
    _("After the Dot-Bomb: Getting Web Information Retrieval Right This Time"
     | http://firstmonday.org/issues/issue7_7/bates/)
    (on the "<STRONG>ontology</STRONG>" <STRONG>fallacy</STRONG>
    and the effectiveness of <STRONG>specialized</STRONG> (vs conventional)
    dictionaries and thesauruses).
  </LI>
  <LI>Data Management (<STRONG>_(Distributed)</STRONG> _(DBMS))
    <BR>The big problem with _(XML) and relatives, besides the stupid syntax
      <SPAN CLASS="comment"
        >[but see below <A HREF="#NaggumOnSyntax">Erik Naggum on SGML syntax</A>]
      </SPAN>,
      is that they are no more intended only as an interchange format
      but as a data model
      <SPAN CLASS="comment">[Review W3C
        _("XML Query" | http://www.w3.org/XML/Query),
        _("XML Path Language (XPath) 2.0" | http://www.w3.org/TR/xpath20/), ..]
      </SPAN>.
      Evidence of this fact: _("XML:DB Initiative for XML Databases" | http://www.xmldb.org/)
      <SPAN CLASS="comment">[moreover see below <A HREF="#Knox">Rita Knox</A>]</SPAN>.
    <BR>See by Fabian Pascal:
    <UL>
      <LI>_("XML Data Management (The \"Future of DBMS\"), Part 1" | http://www.dbazine.com/pascal6.html).</LI>
      <LI>_("Exchange on Database Design and XML"                  | http://www.dbdebunk.com/dodds1.htm").</LI>
      <LI>_("Exchange on XML"                                      | http://www.pgro.uk7.net/thomas1.htm") -
        "<CITE>_(XML)'s data structure is hierarchic and unless data types,
        integrity and manipulation are added to it (to produce a full-fledged data model),
        <STRONG>just a bunch of tags are not sufficient for self-description</STRONG>
        <SPAN CLASS="comment">[see below <A HREF="#Knox">Rita Knox</A>]</SPAN>.
        But if the three components are added -- which is what is happening in W3C
        -- the result will be the same nightmares that prompted us to
        rid ourselves of hierarchic _(DBMS)s years ago.
        </CITE>".
      </LI>
      <LI>_("The XML Bug" | http://www.dbazine.com/pascal4.html) -
        "<CITE>The hierarchic approach underlying _(XML) does, in fact, have a formal
        foundation: <STRONG>graph theory</STRONG>. But as the _("XML 1.0 specification"
      | http://www.w3.org/TR/2000/REC-xml-20001006)
        explicitly states
        <SPAN CLASS="comment">[<STRONG>find how and where that is asserted</STRONG>]</SPAN>,
        it does not adhere to to the theory. The reason is the same as that for which old hierarchic database
        management (e.g., IBM's IMS) eschewed the theory too: it is extremely complex.
        </CITE>";
        <SPAN CLASS="comment"
             >[see below <A HREF="#Codd">E. F. Codd</A>]
          <BR>[<STRONG>Note</STRONG>: investigate the use of <STRONG>category theory</STRONG> to data modelling
               (see _(Category Theory 101)). How that is different from using <STRONG>graph theory</STRONG>?
               In particular the work by Zinovy Diskin and Boris Cadish (see their papers on
              _(CiteSeer | http://citeseer.nj.nec.com/cs?q=Zinovy+Diskin+Boris+Cadish&submit=Search+Documents&cs=1))]
        </SPAN>.
      </LI>  
    </UL>
  </LI>
</UL>
<SPAN CLASS="comment">[Insert here a comment about the wasting and unreliability
of actual search engines, which are a _(centralized), little scalable solution,
 <STRONG>vs</STRONG> a true _(Distributed) DBM/IR Systems].</SPAN>

Essay by _(Tim Berners-Lee):
<UL>
  <LI>_("Relational Databases on the Semantic Web" | http://www.w3.org/DesignIssues/RDB-RDF.html),
      here he does not make much sense, but it's too big to comment
      <SPAN CLASS="comment">[make a comment in another node?].</SPAN>
  </LI>
</UL>

<H4>Weakness of the Hypertext model: <STRONG>links</STRONG>!</H4>
<SPAN CLASS="comment">[Review W3C _("XML Linking Language (XLink)"
| http://www.w3.org/TR/xlink/)].</SPAN>

We can stress the weakness of traditional links with various contrasts,
different in terms but similar as concepts expressed, for example:
<UL>
  <LI>explicit <STRONG>vs</STRONG> implicit (declarative/computable/lazy) associations/constraints
    <BR>(in fact, at least for local/on site links,
      at least when there is a _(DBMS) backend, they are usually generated
      and are there only for _(UI) purpose; see, for example, e-commerce sites);
  </LI>
  <LI>or associations by references/pointers <STRONG>vs</STRONG> associations by values (relational algebra/calculus);</LI>
  <LI>or address-based <STRONG>vs</STRONG> content-based (_(Robust Hyperlinks));</LI>
  <LI>or one way <STRONG>vs</STRONG> two ways links;</LI>
  <A NAME="Codd"><LI>or the "Access Path Dependence" problem as E. F. Codd defined it in
    _("A Relational Model of Data for Large Shared Data Banks" | http://www.acm.org/classics/nov95/s1p2p3.html).
  </LI>
</UL>

Essay by _(Tim Berners-Lee):
<UL>
  <LI>_("Links and Law: Myths" | http://www.w3.org/DesignIssues/LinkMyths.html),
      in which he raises interesting points about the right to make reference
      to work of others (here he makes sense).
  </LI>
</UL>

<H4>Weakness of HTTP (with which people are continually confronting):</H4>
<UL>
  <LI>transaction management</LI>
  <LI>session management (HTTP is stateless)</LI>
  <LI>security (but HTTPS)
    <SPAN CLASS="comment">[Also examine censorship-resistant solutions like
    _(Freenet | http://freenetproject.org/)]</SPAN></LI>
  <LI>version management?</LI>
</UL>
<SPAN CLASS="comment">Google for _(\"weakness of HTTP\" | http://www.google.com/search?q=%22weakness+of+HTTP%22")
gives only 7 results (4-jan-2003) .. amazing!</SPAN>

<SPAN CLASS="comment">[Review REST (REpresentational State Transfer
- _(RESTwiki | http://internet.conveyor.com/RESTwiki/moin.cgi))].</SPAN>

<H4>Weakness of Markup Languages:</H4>

<A NAME="Knox"></A>By Rita Knox:
  _("Here's What's Wrong With XML-Defined Standards"
  | http://www.oasis-open.org/cover/xmlPapers200301.html#Knox) -
 "<CITE>.. Wasn't _(XML) supposed to make data shareable? No. _(XML) provides the tools
to define shareable data models, but it does not make them shareable any more
than the alphabet makes every word in the English language understood by anyone 
who speaks English. ..</CITE>"
<SPAN CLASS="comment">[or the "nave",
with "<STRONG>self describing</STRONG>", imply that you don't need agreement
on semantic and pragmatic issues before exchanging information -- _(Mad70)].
</SPAN>

A talk given by Aaron Crane:
_("Does XML Suck? Or: Why XML is technologically terrible, but you have to use it anyway"
| http://xmlsucks.org/but_you_have_to_use_it_anyway/). On the same site
_("The Big List of XML Technologies" | http://xmlsucks.org/xml_technologies/").

_("Why XML is awful" | http://www.itee.uq.edu.au/~leonard/essay/xml.html).

Erik Naggum, maintainer of the _(SGML) Repository at the University of Oslo for nearly 6 years,
before:
<BR><SPAN CLASS="comment">[??? where is it? it was a citation on the front page of an official _(SGML) site ???]</SPAN>

.. and after the _(SGML) cure:
_("Erik Naggum on SGML and DSSSL" | http://www.oasis-open.org/cover/naggumSGML-DSSSL.html"),
_("Arguments against SGML" | http://www.oasis-open.org/cover/naggumAgainstSGML.html").

Also these threads on <STRONG>comp.lang.lisp</STRONG>:
_("Core ideas behind SGML and XML"
| http://groups.google.com/groups?hl=it&lr=&ie=UTF-8&oe=utf-8&frame=right&th=78c0dbe5b5013534&seekm=upg340odrjtsc2%40corp.supernews.com)
and "Re: The Next Generation of Lisp Programmers":
<UL>
  <LI>
    _("Message-ID: <3239282082503601@naggum.no>"
    | http://groups.google.com/groups?hl=it&lr=&ie=UTF-8&oe=utf-8&selm=3239282082503601%40naggum.no)
    - "<CITE>Furthermore, the more you think about things in _(SGML) terms, the more you realize
    that <STRONG>fully explicit hierarchical structure is not enough</STRONG>.
    </CITE>",
  </LI>
<LI><A NAME="NaggumOnSyntax"></A>
    _("Message-ID: <3239316488198320@naggum.no>"
    | http://groups.google.com/groups?hl=it&lr=&ie=UTF-8&oe=utf-8&selm=3239316488198320%40naggum.no)
    <BR><BLOCKQUOTE>
      [..] I related my discovery that syntax matters when I had worked with _(SGML)
      for half a decade.  It is because of the stupid syntax of _(SGML) that things turn
      bad when people try to use it. [..]
    </BLOCKQUOTE><BLOCKQUOTE>
      [..] In many important ways, _(SGML) is its own worst enemy.  It has managed to
      teach information structuring completely backwards.  Instead of making the
      edges explicit but non-intrusive as in _(Common Lisp), the edges are much too
      visible and verbose with the stupid tags that very quickly consume more of
      the large volume of characters in _(SGML)/_(XML) documents than the contents.  I
      am sure it was thought of as useful back when people needed to be converted,
      but once converted, it gets in the way more than anything else and leads
      people to make mistakes if they do not think very carefully about what they
      try to do. [..]
    </BLOCKQUOTE>
</LI>
</UL>
