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

[Ken MacLeod]

"Michael Champion" <mike.champion at sagus.com> writes:

> Groves, on the other hand, is an extremely general framework,
> somebody in this thread called it a "Grand Unified Theory of
> Information".  It would appear that the groves paradigm is general
> enough to encompass just about any XML or non-XML data model --
> including the DOM's implicit data model, the Info Set data model,
> RDF (?), etc
> 
> But this very generality puts it at a level of abstraction that is
> simply not appreciated by most people trying simply to get their
> jobs done.  I'm VERY sure that had the DOM working group somehow
> proposed an API that consisted simply of an EvaluateQuery() method
> it would have been soundly rejected by the W3C membership or failing
> that, gotten absolutely nowhere in the marketplace of ideas.  It
> simply would not solve any of problems the DOM is intended to solve,
> i.e., it doesn't make it any easier to develop an interoperable Web
> site or XML application, maintaining the maximum possible degree of
> compatibility with languages, tools, and APIs in widespread use.
> What we did come up with is, well, what you call "ad hoc" and I call
> "pragmatic": not pretty, flawed in many ways, but highly serviceable
> and widely adopted.

[I'm reiterating]
> But this very generality puts it at a level of abstraction that is
> simply not appreciated by most people trying simply to get their jobs
> done.

I don't agree.  Most people (noting the target audiences) understand
the idea of nested objects/nodes.  What's trying to be described here
is that it should be very easy to have an API to access those
objects/nodes that doesn't have a hardcoded idea of what the
properties and values of those objects/nodes.  With an API that isn't
hardcoded to one set of properties it becomes natural, intuitive even,
to be able to apply that API to any set of properties.  I believe
people would quickly come to appreciate that.

In some languages, accessing the properties of a particular object are
part of the syntax of the language (ECMA Script, Python, Perl, ...).
In other languages this can be simulated easily using container class
interfaces/protocols (Java, C/C++, SmallTalk, ...).  Trying to address
a deeper level of properties is what most languages or container
classes don't support natively and where query methods come into play,
i.e. node.query().

The most difficult concepts about groves are not basic access to
properties.  One of the most difficult concepts about groves is that
the user gets to choose what level of detail they want to see in a
grove at any particular time.  DOM is well noted for having too much
or too little information for many users, what if the user could
choose?

One concept that is actually very easy for users, but difficult for
grove implementors, is the concept of addressability.  The description
of groves goes into great detail on what it means to point into a
grove.  For users, it's as easy as ``get characters 1 through 50 of
paragraph 3 of node with id "foo-node"'', even if those characters
span multiple nodes.

I understand why it's hard to approach groves, all the grove
descriptions I'm familiar with try to cram all of the concepts into
one document while using the SGML property set as an example.  I have
some ideas for another introduction but I'll need to become more
familiar with some of the richer implementations, mine is just a bit
too primitive to do groves full justice ;-)

-- 
  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)