xml-dev - DOM and Grove

[Paul Prescod <paul@prescod.net>]

Imagine that you had been trained for several years on the ODBC API. Now
you go to university and a professor starts talking about the
"relational database model." You might ask: "how is that different than
ODBC." The answer is that ODBC is a particular representation of the
relational model for programming languages. The DOM can be considered a
particular representation of the grove model for programming languages.

But the ODBC versus relational model is not quite sufficient to capture
the difference. ODBC was built on top of the relational model. The DOM
people used the grove model "for ideas" but the DOM is not based on any
well-defined abstract model at all -- not the grove, not the information
set, not the relational model, not anything. This is reflected in its
odd mix of methods, properties and names "getElementsByTagName"
"TagName", "NodeValue" etc. It's notion of iteration and state is famous
for being rather odd. The DOM is more like a pre-relational API in this
regard.

The major difference between the DOM and an API that could be built on
top of groves (such as that created by James Clark or by GroveMinder) is
that the DOM model is to add support for different data types one by one
through a central committee.

But the important thing to recognize is that the grove is not an API. It
can get lost in Steve's understandable focus on GroveMinder but the use
of the grove as an API is an implementation optimization (in the sense
of optimizing programmer time). The real reason groves were invented was
to answer the question:

 * what is the result of hyperlinking into an arbitrary media type?

What are the properties of the abstract object returned? The grove
answers that question: the object has properties such as "parent",
(possibly null), "children" (possibly null), "containing entity" and so
forth.

You cannot build a sophisticated hypertext system without answering that
question. This will become apparent after XLink, XPointer and RDF are
implemented. We'll start to see many divergences of behavior when links
are made into (e.g.) PDF, MPEGs, JPEGs and so forth. Over time we will
need to develop a framework for describing the correct results of links
in a generic way. Then we will reinvent groves.

Or not... we could keep doing things in an ad hoc manner for ever I
suppose. It would be expensive and inefficient but it is possible.

 Paul Prescod

Daniel Veillard wrote:
> 
> > Daniel said:
> > ------------------------------------------------
> >  When faced with "groves" I still have a serious problem with both
> > points:
> >    - Show me a definition so that I can understand the term and
> >      underlying concept clearly enough that an implementation
> >      time is spend not collecting and reading papers but implemening
> >      something well defined.
> >      Even reading http://www.prescod.net/groves/shorttut/ I still can't
> >      get a clear definition of "what is a grove precisely".
> >      Not at the concept level, but a implementable definition say
> >      on top of the XML infoset (for XML documents).
> >
> > Didier says:
> > ------------------------------------------------
> > I agree with you on that point. Actually groves are defined as abstract
> > entities and there is no common API to groves (each implementer ca define
> > its own interface).
> 
>   Ok, having followed the http://www.netfolder.com/DSSSL/ link and
> looking at http://www.oasis-open.org/cover/topics.html#groves
> The following seems at least a clear and concise definition:
>   In HyTime ISO/IEC 10744:1997 "3. Definitions (3.35)": graph
>   representation of property values is 'An abstract data structure
>   consisting of a directed graph of nodes in which each node may be
>   connected to other nodes by labeled arcs.
> 
> Ahhh ... and
> 
>   GROVE - "Graph Representation of Property Values."
> 
>  Ok, this becomes clearer.
> And the picture clarify it even more !
> 
>   http://www.cogsci.ed.ac.uk/~ht/grove.html
> 
> > Daniel says:
> > -----------------------------------------------
> >    - Show me the code. Not that there is none, I just don't know.
> >      Is there a program available in source code, that I can run
> >      on say a laptop in front of a novice (but programmer kind)
> >      audience (say a Gnome developper's group) allowing me in 3 mn
> >      to show a "grove" in action and what it does for them.
> >
> > Didier says:
> > -----------------------------------------------
> > Easy, just use the "Linux of the markup technologies" aka OpenJade. The code
> > is freely available, several developers around the globe are already
> > improving it each day. The source code is stored on a CVS server and like I
> > said, is freely available. OpenJade includes the SGML grove plan but the
> > grove is transient (i.e. resident on the heap). This is a stand alone module
> > that could be reused in other code. The grove is available as a DCOM object
> > or a C++ object. You may make your own implementation if you want or change
> > the interface. For more information:
> > http://www.netfolder.com/DSSSL
> 
>   Ok, coincidentally i'm doing something similar it seems on top of my XML
> parser except that I based my node structure on a DOM point of view:
> 
>    http://rpmfind.net/veillard/XML/
> 
>   Is there a clear distinction between the model exposed by a DOM API
> and a grove, I can't even find a single DOM reference in
>   http://www.oasis-open.org/cover/topics.html#groves
> 
>  Looking at Henry graphic, it's nearly 100% equivalent to what I build
> so I'm wondering, but I remember people pointing out that those are
> different.
> 
>     thanks for the pointers,
> 
> Daniel
> 
> --
> Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes  | Today's Bookmarks :
> Tel : +33 476 615 257  | 655, avenue de l'Europe | Linux, WWW, rpmfind,
> Fax : +33 476 615 207  | 38330 Montbonnot FRANCE | rpm2html, XML,
> http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe.
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
> 
> FFrom zope-admin@zope.org  Thu Sep  9 07:46:39 1999
> Received: from lambe.pair.com (lambe.pair.com [209.68.1.135])
>         by amati.techno.com (8.8.8/8.8.8) with ESMTP id HAA02271
>         for <prescod@amati.techno.com>; Thu, 9 Sep 1999 07:46:33 -0500
> Received: from zope.codeit.com (www.zope.org [209.67.167.110]) by lambe.pair.com (8.9.1/8.6.12) with ESMTP id IAA18429 for <paul@prescod.net>; Thu, 9 Sep 1999 08:46:32 -0400 (EDT)
> X-Envelope-To: <paul@prescod.net>
> Received: from www2 (localhost [127.0.0.1])
>         by zope.codeit.com (8.9.2/8.8.7) with ESMTP id FAA05917;
>         Thu, 9 Sep 1999 05:37:21 -0700 (PDT)
> Received: from erwin.complete.org (erwin.complete.org [209.197.212.34])
>         by zope.codeit.com (8.9.2/8.8.7) with ESMTP id FAA05895
>         for <zope@zope.org>; Thu, 9 Sep 1999 05:37:15 -0700 (PDT)
> Received: (from jgoerzen@localhost)
>         by erwin.complete.org (8.9.3/8.9.3/Debian/GNU) id HAA01185;
>         Thu, 9 Sep 1999 07:36:55 -0500
> Sender: jgoerzen@erwin.complete.org
> To: "Phillip J. Eby" <pje@telecommunity.com>
> Cc: zope@zope.org
> Subject: Re: [Zope] <!--#local--> and <!--#set--> (was Re: Proper way   to set variables)
> References: <John Goerzen's message of "Sun, 5 Sep 1999 23:08:39 -0500"> <199909060408.XAA26630@erwin.complete.org> <3.0.5.32.19990908171639.0090f6e0@telecommunity.com>
> Mime-Version: 1.0 (generated by tm-edit 7.108)
> Content-Type: text/plain; charset=US-ASCII
> From: John Goerzen <jgoerzen@complete.org>
> Date: 09 Sep 1999 07:36:55 -0500
> In-Reply-To: "Phillip J. Eby"'s message of "Wed, 08 Sep 1999 17:16:39 -0500"
> Message-ID: <87btbc5kig.fsf@erwin.complete.org>
> Lines: 56
> X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
> Sender: zope-admin@zope.org
> Errors-To: zope-admin@zope.org
> X-Mailman-Version: 1.0b8
> Precedence: bulk
> List-Id: Users of the Z Object Publishing Environment <zope.zope.org>
> X-BeenThere: zope@zope.org
> 
> Excellent, this sounds like exactly what I need to fix.  Can you send
> the patch along to me?
> 
> "Phillip J. Eby" <pje@telecommunity.com> writes:
> 
> > At 02:02 PM 9/8/99 -0500, John Goerzen wrote:
> > >Heh, feels strange to reply to myself, but as I got no replies before,
> > >maybe I need to elaborate a bit.  The original question is below.
> > >
> > >My main confusion is just how do I set a variable that is dynamically
> > >scoped without having to use dtml-with or dtml-let, both of which
> > >require matching closing tags?
> > >
> >
> > FYI, I have just written a patch for DT_Let.py that adds two new tags,
> > 'local' and 'set'.  They are used like this:
> >
> > <!--#local myvar1="0" myvar2=somevar-->
> >
> >
> > <!--#set myvar1="myvar1+myvar2"-->
> > ...
> > <!--#set myvar2="myvar2+1"-->
> >
> > <!--#/local-->
> >
> >
> > Both <!--#local--> blocks and <!--#set--> tags are dynamically scoped and
> > <!--#set--> can be used anywhere as long as there is an enclosing
> > <!--#local--> block defining the variable you want to set.  You can only
> > set variables which are defined by the innermost <!--#local--> block, but
> > you can reset their value any number of times, even within the same
> > <!--#set--> tag.
> >
> > I am currently testing this code in an alpha app, but will be submitting it
> > some time in the near future to Digital Creations for consideration of
> > inclusion in future Zope versions.
> >
> >
> > _______________________________________________
> > Zope maillist  -  Zope@zope.org
> > http://www.zope.org/mailman/listinfo/zope
> >
> > (To receive general Zope announcements, see:
> > http://www.zope.org/mailman/listinfo/zope-announce
> >
> > For developer-specific issues, zope-dev@zope.org -
> > http://www.zope.org/mailman/listinfo/zope-dev )
> >
> 
> --
> John Goerzen   Linux, Unix consulting & programming   jgoerzen@complete.org |
> Developer, Debian GNU/Linux (Free powerful OS upgrade)       www.debian.org |
> ----------------------------------------------------------------------------+
> The 176,239,285th prime number is 3,697,131,523.
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://www.zope.org/mailman/listinfo/zope
> 
> (To receive general Zope announcements, see:
> http://www.zope.org/mailman/listinfo/zope-announce
> 
> For developer-specific issues, zope-dev@zope.org -
> http://www.zope.org/mailman/listinfo/zope-dev )
> 
> rom python-list-request@cwi.nl  Thu Sep  9 07:46:40 1999
> Received: from smv03.iname.net (lmtp06.iname.net [165.251.8.61])
>         by amati.techno.com (8.8.8/8.8.8) with SMTP id HAA02274
>         for <prescod@amati.techno.com>; Thu, 9 Sep 1999 07:46:33 -0500
> Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.1])
>         by smv03.iname.net (8.9.3/8.9.1SMV2) with ESMTP id IAA05852
>         for <papresco@technologist.com> sent by <python-list-request@cwi.nl>; Thu, 9 Sep 1999 08:46:32 -0400 (EDT)
> Received: from localhost by hera.cwi.nl with ESMTP
>         id OAA04566; Thu, 9 Sep 1999 14:31:17 +0200 (MET DST)
> From: Guido van Rossum <guido@cnri.reston.va.us>
> Newsgroups: comp.lang.python
> Subject: Re: SocketServer on NT slow for large transactions
> Date: 09 Sep 1999 08:11:28 -0400
> X-Organization: Corporation for National Research Initiatives
> Message-ID: <5logfc474f.fsf@eric.cnri.reston.va.us>
> References: <7r7ipf$lqj$1@news.duke.edu>
> X-Trace: ffx2nh5.news.uu.net 936879095 16700 132.151.1.38 (9 Sep 1999 12:11:35 GMT)
> X-Complaints-To: news@ffx2nh5.news.uu.net
> X-Newsreader: Gnus v5.6.45/XEmacs 21.1 - "Big Bend"
> To: python-list@cwi.nl
> Sender: python-list-request@cwi.nl
> Errors-To: python-list-request@cwi.nl
> 
> "eric jones" <ej@ee.duke.edu> writes:
> 
> > I wrote a very simple program using based on the
> > SocketServer.StreamRequestHandler, and found that it crawled along at a
> > snails pace.  I've traced the problem to the socket._fileobject.
> 
> Yes.  This has been fixed in the CVS version though -- see
> python.org/download/cvs.html.
> 
> --Guido van Rossum (home page: http://www.python.org/~guido/)


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)