xml-dev - Another try on groves

[Paul Prescod <paul@prescod.net>]

Imagine that you are a Mozilla programmer. One day you are trolling
through the XML family of specifications and you notice that RDF and
XLink offer some intriguing possibilities.

RDF allows you to associate, let's say, ratings with components of XML
documents. So you could have a big XML document representing a Slashdot
forum and you could use RDF to hide the articles ranked as trolls. Using
RDF all of this could be done on the client side using sophisticated
Mozilla-built in features. Of course a decent programmer would not
restrict the feature to Slashdot, or to online forums but to any XML
document with ratings described by RDF.

Using XLink you could also allow links to be imposed. These could point
to other documents on the Web that relate to the current conversation.
They could also be annotations by non-slashdot members.

A light comes on. Now you understand what these specifications were
meant to allow.

So you start madly implementing. As you are about a third of the way
through you notice that the RDF and XLink specifications do not
explicitly limit their targets to XML. ANY media type with a fragment
identifier can be described by RDF or linked by XLink. Uh oh. Things
just got a lot more complex. You can now address into PDFs, MPEGs,
ShockWaves and CorelDraw graphics. Of course Mozilla supports those
formats though third party plug-ins. You don't even have the code to
them...the only way to influence them is to improve the plug-in API.

Now you have a choice: you can subvert the intent of the RDF and XLink
specifications by pretending that they only apply to XML or you can step
up to the challenge of implementing the features in a manner that does
not discriminate against non-XML media types. Obviously MPEG movies are
not going to be XML documents in our lifetimes.

If you are in a hurry you might jump to the conclusion that the best way
to address into these media types is either to convert them INTO XML
(perhaps reasonable for PDF) or at least have them expose their
properties as a DOM. 

The problem with being in a hurry is that you end up wasting time. You
will waste time here because the impedence mismatch between MPEGs and
the DOM is going to be huge. A frame is not an "element", it has no
"attributes". Now I claim that a frame is an object and that it has
properties. And any idiot knows that objects can be represented in XML
using a variety of techniques but think about the logic of doing it this
way: you are taking a thing that is "logically" an object, expressing it
in terms of a text file format so that another module in the same
process can re-interpret it as logical objects.

The *only good reason* to dumb something down into XML elements and
attributes is to move the information between processes separated by
space, time or incompatibility. Using XML as the "universal API" is
madness because there *is no universal API*. The idea is patently
ridiculous. (some Unix evangelists have claimed that open/read/write is
hte universal interface but actual Unix usage demonstrates that this is
not even close to true...look at the heavy usage of CORBA and IDL in
Unix GUIs)

The term "dumb down" is not an insult against XML or the DOM. After all,
the act of representing something as XML necessarily "dumbs down" the
XML to Unicode characters but that can hardly be considered an insult
against Unicode! Representing Unicode requires a dumbing down into
octets which are dumbed down into bits to be sent across the wire.

All of this dumbing down is great when it is necessary but inconvenient
and inefficient when it is not.

So as a Mozilla programmer your next step is to define a base class for
"linkable objects". Let's call those "nodes." In order to navigate
around these nodes it is useful (some claim necessary...I believe them
but have not verified this for myself) to have the nodes have properties
like "parent", "children", and so forth. 

Yes, this is very DOM like but the big difference comes in the next
step: the next step is that the "properties" of these things can be
rich  -- not "dumbed down" to elements and attributes. This not only
removes two layers of code (dumbing down and building up) it also
removes a lot of potential for confusion: "the object's principle light
source property is represented by a reference to a principle light
source element which represents a light source object. Go read the
documentation to see how a light source object is represented in our DOM
representation."

Why not represent a "principle light source" property with a property
named "principle light source" and why not let its value be a real
object (not an element) with properties that are also real objects.

Okay, so what else do we need in our "node" ("linkable object")
interface? Well, runtime discoverability of node types and properties is
useful in any language and absolutely required if we are going to expose
our objects in a dynamically typed language like Javascript or DSSSL. So
we need methods that allow us to find out the node's class and property
list.

This base "interface" is known in grove terms as the "intrinsic
properties." They aren't just magical hidden features -- they are
properties just like "principle light source" and "element type name."

There's an important operation we need every pair of nodes to support:
given two node references we need to be able to figure out if they are
to the same node. If we are going to make a list of all opinions about a
particular Slashdot posting then we need to be able to recognize when
multiple links are talking about the same thing. This is why I've harped
in the past, on this list, about object identity. Linking is not going
to work properly unless we figure it out.

Arguably, object identity is the *whole point of groves*. But of course
there is more.

Now consider that some applications work on all XML document types but
many work on only a particular document type. The same holds for COM
objects. The same holds for groves. Some will work with any old grove
(e.g., a hyperlink database) but a renderer will require a particular
set of node types. 

Just as we have a schema to allow XML documents in a class to be
consistent we have a schema for groves called a "property set." This can
even be compiled into a header file in a strongly typed programming
language (just like a COM type library or OLE class).

Here are what I consider the crucial points of this discussion:

 * existing web technologies will not "work properly" without a data
model for linkable, annotable data. These technologies implicitly depend
upon this model that *does not exist*. Call it a universal data model,
meta data-model, meta, meta, data-model, whatever. It needs to exist.

 * near-term software applications will run up against the lack of this
model not in the distant future but in years or months. Arguably they
have *already* run up against the problem of the lack of this model. The
XML information set is a stop-gap for applications that are all XML but
this is supposed to be a hypermedia web -- the stopgap can only hold for
so long.

 * there is nothing futuristic about groves. They take some basic ideas
from the information set, add them to some basic ideas from COM/CORBA,
add in a few original ideas specific to the hyperlinking domain and
that's it. Groves only seem abstract because most people are still
confused by and scared of linking applications. The (IMHO) chaotic
development of linking and annotative specifications and software on the
Web is a symptom of this same problem.

 Paul Prescod

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)