xml-dev - RE: Groves, IsNess and the Generic Data Object. [was.. Another try on Gr

["Graham Moore" <gdm@step-dpsl.co.uk>]

I have a ramble that I constructed the other day and some additional
comments about other postings.

Comments:

---------------------
************************* ---------------------------------

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.

Consider..

root node
|
----- 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
an S-Expression.

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.

---------------------
************************* ---------------------------------

Domain:

how about

www.grove-paradigm.com

In essense there is more to the grove paradigm than just the model, e.g. the
notation processor
that constructs the model, the property set defintion, the grove plan,
application conformance, suggested API's.

---------------------
************************* ---------------------------------

Ramble:

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
grove paradigm.

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
brings.

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
rigour.

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

<doc>
	<car colour="red"/>
</doc>

I can only say if I have a grove of the XML doc

print node.attribute.name
colur

print node.attribute.value
red

Now, if I have a grove that represents the object car

I can say

print node.colour
red

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.

Summary

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.


Kind Regards,

Graham.

*------------------------------------------
* Graham Moore
* Consultant STEP-DPSL
* gdm@step-dpsl.co.uk
*------------------------------------------













________________________________________________________________________________
This message has been checked for all known viruses by the Star Screening System
http://academy.star.co.uk/public/virustats.htm

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)