Groves, IsNess and the Generic Data Object. [was.. Another try on Groves]
gdm at step-dpsl.co.uk
Mon Sep 20 10:37:32 BST 1999
I have a ramble that I constructed the other day and some additional
comments about other postings.
I saw the following from Sean
>>I believe it makes perfect sense to *think* of MPEGS, PDFs,
>> whatever, in XML terms.
This is NOT what groves are about. Groves are about thinking about the
'IsNess' of things.
XML is one thing you could get as a serialisation of a grove model.
----- named prop 1 - type node
----- named prop 2 - type basic
----- named prop 3 - type basic
----- named prop 4 - type node
----- named prop 5- type basic
----- named prop 6 - type basic
Above is the abstract data model for a thing. It could be any thing. There
is NO XML I have
just captured the 'IsNess' the first class properties of the thing. I have
not thought about XML I have thought about the properties of the thing.
Now, if I decided that I need a serialisation of my grove then I need
to choose a mechanism for that. Section A1.4.5 of HyTime 2nd Edition
provides us with the
canonical representation for doing such a thing.
Obviously the canonical representation is defined in terms of an SGML DTD
and thus I could
create XML and SGML instances for my grove model. Equally though I could
serialise the model as
I think the point is that the grove paradigm should not get people to think
in terms of XML
but in terms of better appreciation of the properties of the notations they
are dealing with.
I agree that the concept that groves can be seen as a way to add tags to
untaggable data as
very powerful. But the more general case is that the grove paradigm gives
names and first
classness to otherwise unaddressable properties.
In essense there is more to the grove paradigm than just the model, e.g. the
that constructs the model, the property set defintion, the grove plan,
application conformance, suggested API's.
I think paul should be applauded for making groves more accesible in his
last few mails.
I wanted with this mail to re-iterate some of what Paul said and add what I
feel is the essence of the grove paradigm. In addition I wanted to present
the Generic Data Object concept and its role in the grove paradigm. I also
wanted to give some concrete explanation and focus as to the power of the
It is the concrete focus that I want to start with,
The most striking difference between XML and a Grove Model is that in the
domain of 'cars' an Grove will let you access the value of the 'door'
property, the grove for the XML representation of the car will let you
access an 'attribute' of an element that is a serialisation of the object
'door'. As Paul said, Groves remove a level of redundant indirection.
Why did I give the above example? I feel that this is such a **fundamental**
concept that it is worth exemplifying as much as possible. Secondly I need
it to lead on to the essence of of the grove paradigm and the power it
Object Oriented development is now established, we identify our entities,
they have properties and we implement them using our favourite OO langauge.
Now it happens that most peoples favourite OO lanaguge is not a dynamic
beast such as Scheme, Python or CLOS but a strongly typed langauage such as
Java or C++, there is nothing wrong with this. We construct these classes
for specific roles - see UML and the fact that classes are assigned roles
within a system. We value this as it gives us robust design, better error
handling etc etc.
Now, what if we still had some of the rigour of the typed system but one
that could be dynamic and applicable to a variety of applications. Very
nice but how does this apply to the grove paradigm.
1) When you build a grove model it adheres to a property set this is in
effect equivalent to a set of UML class definitions. So this gives us our
2) When you build a grove model it is typically constructed in memory as an
object model. This model is constructed by a 'Notation Processor'. A
Notation processor is aware of the property set and is also aware of a
Notation or number of Notations. A Notation is a ***'thing'***. This thing
could be a Network, a Car, a Document, An application, a person, any given
data notation. Thus given a networks property set and given a network
instance a Notation processor can construct a Grove Model that allows
access to all the properties of the network as first class objects. Before
we come onto first classness and isness how can we build these heterogenous
object models. As was pointed out in a previous mail heterogeneous
collections play a big role in computing. The grove paradigm perceives that
Objects are just containers with a generic collection of key, value pairs.
The grove paradigm works at a fundamental level of computing, values
associated with names. This is achieved by having the Generic Data Object.
The GDO has closure in that it always returns a value which could be another
GDO, it is dynamic as new values can always be added. These properties
ensure that no matter what the notation is a notation processor can create
a grove model that can contain the named property values of that notation.
The Power of Groves....
The value of OO is in having something, an entity, that is malable,
touchable, something that can be manipulated. Many systems are not
empowered as they do not have their assets, their properties as first class
objects. The grove paradigm provides the ability to make everything first
class. e.g. the thread on the bolt on the door of a car becomes a node - a
malable object - within the grove paradigm.
Now, in the world of groves we only ever have nodes and properties thus if
we have 1000 notations that have notation processors for them then we have
a abstract data model for *all* these notations. We can interchange these
nodes at the abstract level, we can link bewteen nodes at an abstract level
without needing to know about the details of the underlying notation. I can
link from my thread on the bolt on the car to the procedure of screwing on
the nut in a technical manual. Note - that the thread on the bolt IS the
thread on the bolt not a *document* about the thread on the bolt.
Why the confusion with Groves and XML
It appears that the dynamism and extensibility of XML and Groves provides a
good match. The thing to remember is that the Property set for every XML
document is the same. I never have the property 'colour' on a grove node for
an XML document I only ever have 'attribute', 'name', 'value', 'gi'
e.g. given this XML doc
I can only say if I have a grove of the XML doc
Now, if I have a grove that represents the object car
I can say
The general grove model provide *IsNess* you talk about the thing as it IS,
you talk about something in terms of the properties that help form its
instance identity [identity obviously exists beyond the properties and their
value]. The IsNess of an XML document is about attributes, elements and
their values. The IsNess of a car is parts, colour, engine power etc.
The grove model enables a level abstract playing field in which to bring all
notations - things. This is possible through the use of Generic Data
Objects and their inherent dynamism and closure property. The grove paradigm
helps us understand the essence of a notation so that we may manipulate
*any* aspect of it.
* Graham Moore
* Consultant STEP-DPSL
* gdm at step-dpsl.co.uk
This message has been checked for all known viruses by the Star Screening System
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