ANN: XML and Databases article

[Ken MacLeod]

"Didier PH Martin" <martind at netfolder.com> writes:

> Hi Daniel,
> 
> 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).

> I suggest also that you take a look at the PERL open source project
> because they too have included a grove manager in the PERL
> package. Did you noticed that PERL already implemented a Grove
> module?

That would be the Data::Grove (in libxml-perl) module and it's only
current set of node classes, the XML::Grove module.  If you'd like to
look at a very simple implementation of groves, those would be the
ones.

In Data::Grove, ``nodes'' are Perl objects (named, or ``blessed'',
hashes), node-lists are Perl arrays, and named-node-lists are
un-named, or ``anonymous'', hashes.  Even though nodes are ``objects''
they are still accessed directly using Perl hash syntax (i.e. there
are no accessor methods).  (The same could be done as easily in any
language, of course.)

In the current implementation of Data::Grove the grove is ``passive''
-- the view, or ``grove plan'', of the grove is fixed at the time the
grove is built, there's no support for enforcing constraints, and
character data does not appear normalized.

This differs from other grove implementations which I would call
``active'' -- the view of the grove can be changed dynamically,
constraints are checked and/or enforced, and groves always appear
normalized.  Grove plans were described in another message, but an
example is where you could choose to see entity reference nodes in the
grove or just the characters that replace the entity reference.

Groves are often compared to DOM.  In grove terms, DOM Level 1
presents two very specific grove plans, Core and HTML.  DOM defines
these grove plans in terms of accessor methods for specific properties
and a fixed set of constraints.  In contrast, groves act more like
generic containers.  The API for accessing the generic containers is
left to the implementation, property and value constraints are defined
seperately, and the user is allowed to choose which set of property
and value constraints to use at any particular time.

Simply put, the idea behind groves is to seperate the definition of
properties from the API used to access those properties.

-- 
  Ken MacLeod
  ken at bitsko.slc.ut.us

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)