xml-dev - Re: ANN: XML and Databases article

[Ken MacLeod <ken@bitsko.slc.ut.us>]

Ronald Bourret <rbourret@ito.tu-darmstadt.de> writes:

> Steven R. Newcomb wrote:
> 
> > > What other common functions can you perform besides addressing /
> > > hyperlinking?
> >
> > Anything that you can do with markup -- and that covers a lot of
> > territory.  Especially, anything that you can do with markup, but
> > can't, for one reason or another, use markup to do.  (E.g., you can't
> > change what you want to mark up, or what you want to mark up can't be
> > marked up without making it useless for its intended purpose.)
> >
> > A better question might be, "What *can't* you do if you have the
> > ability to attach any information at all, for any reason whatsoever,
> > to any other piece(s) of information, without changing any information
> > except for creating the attachment instructions (which can be
> > completely separate from everything else), in such a way that an
> > application can always tell what is attached to what?"
> 
> I'm still not getting it.  I honestly can't think of much to do with
> markup except marking up data.  Most of the things I can think of
> doing I do with data -- the markup just tells me what the data
> means.

In the paragraphs quoted above, Steven is referring to a benefit that
well-defined addressing provides -- the ability to attach ``markup''
to instances you don't control (owned by others or on read-only
media).  This benefit can only be gained if consistent addressing is
available, which the grove paradigm goes to great lengths to define.

> Let me try asking the question in this way: what facilities do I
> inherently get from using groves and their related technologies that
> I can use in a generic manner? For example, in the XML world, I can
> pass the data around in a text file, navigate it with the DOM, link
> to other data with XLink, query the data with XQL, transform it with
> XSL, and so on and so forth.  So far, what I've heard about groves
> tells me that I can express any data as a set of objects, I can
> navigate through those objects, and I can build links between any of
> those objects, regardless of their class.  What else can I do?

What more are you expecting?  If we were to say that groves provide
all the same functions you attribute to the XML world but without
being tied to XML specifically, wouldn't that alone be worthwhile?

The grove paradigm results from recognizing that the same functions
you attribute to XML actually apply to many different sets of data.
Hence APIs, link languages, query languages, transformation languages,
and so on and so forth that can be used in a generic manner across
many different sets of data.

Note that in many cases, the tools and specs for working with XML can
easily be adapted to work with groves.  In general (and IMO), XML
tools and specs are much simpler than several existing SGML-derived
grove tools and specs, just as XML is to SGML.  I believe adopting
those tools and specs would be a great addition to the grove world.

[somewhat out of context :-) ]
> We're not going to see an all-grove world any time soon

I agree, I don't see the W3C or the community just changing direction
based on promise alone (even if there are implementations currently
available).  I believe it's high time (pun not originally intended ;)
that grove advocates banded together and started promoting groves more
directly: build a web site, create a mailing list, start drafting
grove APIs where they're not already, adapting XML tools and specs,
etc.  I would be glad to start working on much of the administrivia,
the first need would be for a solid mail-list host, offers?

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

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)