Another try on groves
francis at redrice.com
Mon Sep 20 00:13:20 BST 1999
Ken MacLeod wrote:
> Francis Norton <francis at redrice.com> writes:
> > Now that I have some feeling for the rationale behind Groves, I'd be
> > very interested in knowing what this might mean for implementations.
> > Could one come up with a language independent API like the DOM, to
> > which Grove compliant APIs would conform? Presumably there is more
> > complexity in that the DOM has a closed set of underlying object
> > types whereas each Grove interface would would have different
> > underlying object types. In Java terms, would this be an interface
> > (a totally abstract class which guarantees a core functionality in
> > any object which implements it)? Has anyone in fact built CORBA IDL
> > or a Java interface defining the Grove API, or am I coming in at the
> > wrong level?
> I'd like to believe you're coming in at the wrong level. Many
> languages have built-in syntax to access ``members of objects'' or
> ``fields of records'' that can often be applied to accessing
> ``properties of nodes''. In this case, the grove API is the
> language's native syntax.
> Where native syntax is not applicable, groves most closely resemble
> container classes (dictionaries, mappings, hash tables; lists, arrays,
> sequences). Again, a language's standard container class interface or
> protocol can be used.
I've gone back to my copy of Paul Prescod's short tutorial (which I can
no longer find on the 'net - does anyone have a live URL for it?) and
found in section 2.2 a case against the DOM approach of defining an API
"... We have found this very limiting in the Python and Perl worlds.
With these high level languages there are more convenient ways of
mapping the high level XML concepts into APIs than the ways dictated by
So what *is* a grove implementation? For instance I think of a DOM
implementation as a program that includes or harnesses an XML parser and
provides DOM bindings for a language or protocol (such as COM). I know
that it is a DOM implementation because it follows the pre-defined DOM
API - how will I know if something is a Grove implementation?
To extend the Mozilla analogy, would a Grove-compliant world offer our
switched-on programmer (1) a language-dependent but notation-independent
API, so that her clever features could operate, at run-time, on media
that she hadn't specifically supported at build-time; or (2) would it
simply become much simpler for her to support new media at build-time,
even though each new notation would still require explicit coding to
exploit its grove features?
If (2) am I just confusing matters by talking about APIs when perhaps
the real Grove implementation effort is in defining the Grove-compliant
information set for each notation?
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;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev