xml-dev - RE: The Power of Groves

["Didier PH Martin" <martind@netfolder.com>]

Hi Len,

Len said:
My problem here is that we seem to be in an MMTT trap.  That is,
I can point to at least four other languages that claim the
*name* "node".  The trick is to prove that what each calls a node
is the same.

Didier replies:
In a previous post, I specified what is a node in the Grove sense. A node is
a set of properties. Some properties are singleton and others are collection
properties. To create a hierarchy of nodes, we can use a collection of node
property. This recursive behavior allows you to create a hierarchy (if you
want to create a hierarchy of course). For instance, a node of type element
has a "content" property. this latter is a collection property, each member
of the collection property is a node. If we apply the constraint to say that
only text and element node (particular types) are allowed in the collection
then we have specified a particular grove plan.

So, a node in the grove sense is well specified. it is a set.... (go back to
previous paragraph). I just repeated that for those who think that Groves
are just for Mensa members :-)

We are actually working on DSSSL-2 and because DSSSL is a grove manipulation
language, we saw that we need to create a specific document for groves.
Actually Grove specification is embedded in both Hytime and DSSSL. Also, if
we now package Groves specifications in a separate document, we have a
chance to add some elements like class inheritance. Have better examples.
And...have figures that are lacking most of the time in ISO specs.

The Info set group is using RDF to define classes. This is a good idea since
an RDF "frame" is a set of properties. A good point about RDF is that its
schema allows class inheritance. The bad point is that the actual info set
is more resembling fussy sets than anything else :-) I think not because of
lack of WG intelligence (there is plenty of that) but probably more because
of political issues (but in fact, I really do not know the cause of the
fuzziness)

Something particular about the usage of the Grove paradigm. A node can be
composed of properties that come form the document and of properties that
come from an outside source like, for instance, an interpreter. For example,
you first translate an XML document into an XML grove plan so that we have
for the XML element node the following set of properties:

element node
   |____ Qname
   |____ ID
   |____ attributes
   |        |___ Attribute node
   |        |___ Attribute node
   |____ content
           |___ text node
           |___ element node
           |___ element node

Then, an Xlink interpreter could transform this element node into something
new if we say that the link node inherits from the element node (this is
only a sample here to illustrate "live" the behavior of Groves)

So that we have now:
element node
   |____ locators
   |        |___ locator node
   |        |___ locator node
   |____ Qname
   |____ ID
   |____ attributes
   |        |___ Attribute node
   |        |___ Attribute node
   |____ content
           |___ text node
           |___ element node
           |___ element node

You recognized that we now transformed our element node into an xlink
extended node. Or so to speak, that the xlink extended node inherited from
the element node and therefore that an xlink node _is an_ element node. And
so on and so forth.

So Len, Even if you know most of this stuff, I wanted to bring to the table
that:
a) If we show how some w3C technologies could be documented, explained or
using Groves, everybody will gain some comprehension
b) Groves are created by interpreters that build a model after the document
is parsed. We can explicitly say what is in the model and why we used this
or this particular property. Even say which property is coming directly from
the document and which property is filled by the interpreter. (this last
point is often missed in most texts about Groves)
c) We can explicitly say also that the actual DOM is based on a certain
model which is not incompatible with Groves.
d) However, alternative API could be created on Groves that are a lot more
scalable, and less complex. For instance, a JavaScript construct could
access a grove element as: document.element1.locators.locator1 which is
providing more information about the node hierarchy and which is probably
more intuitive to a javascript programmer.

Cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: Web New York (http://www.mfweb.com)
Book to come soon: XML Pro published by Wrox Press
Products: http://www.netfolder.com