xml-dev - [peter@techno.com: Re: [schen@falconwing.com: Re: DOM and Grove]]

["Steven R. Newcomb" <srn@techno.com>]

------- Start of forwarded message -------
Date: Fri, 10 Sep 1999 20:44:38 -0500
From: Peter Newcomb <peter@techno.com>
Subject: Re: [schen@falconwing.com: Re: DOM and Grove]

Hi Dad...  Could you forward my response to xml-dev?

[schen@falconwing.com on Thu, 9 Sep 1999 19:34:44 -0400 (EWT)]
> There's a note in the Property Set Requirements annex of the HyTime
> specification:
>
> NOTE 440 Property sets are designed to support the HyTime and DSSSL
> processing and representation of notation-specific data by providing the
> information needed by those processes. They are not intended as a general
> model for making notation-specific data available for arbitrary
> processing.

I'd like to emphasize the point that this note tries to make, and
possibly clear up its intended meaning.  (After all, I have to take
full responsibility for the obtuseness of the note...)

First of all, this note does not mean that property sets/groves only
really support HyTime and DSSSL notations, but rather that they
support the representation of only those portions of other notations
that are relevant to HyTime and DSSSL engines/applications.  The grove
paradigm is simply HyTime's answer to the question that Paul so
concisely stated:

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

In other words, groves are specifically meant to provide HyTime with
the data abstraction layer that was needed in order to identify
components of documents or information sets.  Note that HyTime doesn't
require that the information itself be accessible through the grove,
only that the components of the information be identifiable.

On the other hand, some types of information lend themselves well to
being modeled as groves.  SGML (and, of course, XML) is such an
information type.  DSSSL takes advantage of this by specifying a
property set that constitutes a complete data model for SGML, and
using it to access the modeled data itself.  Other applications can
also use this model to access SGML data-- for SGML, a grove is a
relatively convenient abstraction for many types of processing.

Of course, groves are not always an appropriate abstraction for data
processing.  It would not be convenient, for instance, to use a grove
model of a video stream to perform a contrast-enhancement
transformation.  It would, however, be convenient to use a grove model
of a video stream to select the range of frames to be enhanced.

Similarly, a grove model of tables in a relational database may not be
a convenient data model over which to resolve queries.  Such a model
would, however, be convenient for representing the result of such a
query.  Even better would be to define the grove model of the database
such that it reflects the intent of the relational schema being used,
in effect defining a view of the database as a single grove.  Queries
against the database would be resolved with respect to the efficient
but possibly non-intuitive relational schema, but the information
found using the queries could be viewed using the, IMHO, more
humanly-understandable grove model.

Of course the main reason that one would want to create a grove view
of any information set is so that that information can participate in
hyperlink and other relationships along with other information that
may be of different types.

- -peter

- --
Peter Newcomb                           TechnoTeacher, Inc.
peter@techno.com                        http://www.techno.com/
------- End of forwarded message -------

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)