[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Groves, the next big thing (Re: ANN: XML and Databases article)

• From: Ken MacLeod <ken@b...>
• To: <xml-dev@i...>
• Date: 09 Sep 1999 12:38:18 -0500

"Michael Champion" <mike.champion@s...> writes:

> Also, even if the "grove paradigm" is a fundamentally more powerful
> way of looking at XML and other types of data than what is in wide
> use today, it's unlikely to be adopted unless there is a clean
> migration path from familiar APIs like ODBC/SQL, the W3C DOM, the
> (forthcoming?)  JCP XML data binding spec, etc.  [...] So, I would
> *love* to see someone define a grove API that extends the DOM,
> and/or to see the grove paradigm cleanly incorporated into the Java
> Community Process XML data binding, and/or to see a
> repository-friendly API that builds from ADO or JDO and incorporates
> groves concepts.

I commented in another message that the idea behind groves is to
seperate the definition of properties and value constraints from the
API to access those properties directly.  The ECMA Script Language
Binding for Level 1 DOM looks deceptively close to that.

In effect, the ECMA Script binding says ``use ordinary ECMA Script
syntax to access the [grove] properties, and here's the definition of
those properties.''  The ECMA Script binding, of course, layers
additional methods specific to XML/HTML (getElementsByTagName, for
example).

If you were to actually seperate out the definition of the properties
from the accessors, modifiers, and XML/HTML specific methods, you
would be very close to a grove paradigm.  You would end up with three
parts to the standard: the grove access (implementation specific, or
language bindings), a property set, and property-set-specific
extensions.  It's the definition of property-sets that the grove
paradigm intends to be more flexible and dynamic.

Another example using the Java binding is if the property
setter/getter methods were to be removed and replaced with a Mapping
interface (or similar).  In this way, the set of properties and
constraints could be factored out into ``driver'' classes as described
in another message.

I'm not proposing this as the ``one true way'' to bridge groves and
DOM, more as a bridge to _understanding_ the relationship of groves to
DOM.  What I'd like to see happen is a proposal or note for a concrete
implementation of a grove directly comparible to the current bindings
for DOM.

-- 
  Ken MacLeod
  ken@b...

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

• References:
  • RE: ANN: XML and Databases article
    • From: David Megginson <david@m...>
  • RE: ANN: XML and Databases article
    • From: Ronald Bourret <rbourret@i...>
  • Groves, the next big thing (Re: ANN: XML and Databases article)
    • From: Mark Nutter <mnutter@f...>
  • Re: Groves, the next big thing (Re: ANN: XML and Databases article)
    • From: "Michael Champion" <mike.champion@s...>

• Prev by Date: Re: Layers, again (was Re: fixing (just) namespaces and validation)
• Next by Date: Re: DOM and Grove
• Previous by thread: Re: Groves, the next big thing (Re: ANN: XML and Databases article)
• Next by thread: Re: Groves, the next big thing (Re: ANN: XML and Databases article)
• Index(es):
  • Date
  • Thread