Groves, IsNess and the Generic Data Object. [was.. Another try on Groves]

[Sean Mc Grath]

Graham,

Thanks for this post. I think this is a useful
discussion...

[Graham Moore]
>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.

In the above you have done what any intelligent, carbon based
life form known to man would have done -- you have structured
a domain model into a *hierarchy* of objects. I look at
your diagram and in my head I see nodes called "named prop 1"
and "named prop 4".  I see other nodes that are contained
within these nodes called "named prop 2" and so on.

That level of abstraction -- nodes -- is all I need to
process this data -- given some simple API. XML
provides such a simple API. I need to simply
mentally map the nodes and arcs into XML
terminology of elements and attributes. This
done, I can write software apace
using SAX, DOM or any other XML API.

Lets pretend the above data is in a data format
known as FOO and accessible in CORBA land via
a FOO-API. You seem to be asserting
that I need a "grove" for this because the
property set mechanism of the grove paradigm
allows me to work in terms of an object
API rather than an XML API. In other
words this:

	# Access instance variable "named prop 5"
	# of object "named prop 4"
	named prop 4.named prop 5

instead of this:

	<named_prop_4 named_prop_5 = "...">

 (or its equivalent (ontological arguments aside))
	<named_prop_4>
		<named_prop_5>...</named_prop_5>
	</named_prop_4>

I don't buy it. I personally do not find the prospect of
programming the latter rather than the former in any way
daunting or limiting. It is a trivial transformation to
take a hierarchy of typed nodes and associated attributes
and create an object hierarchy if I really want to be able
to use "object.instance attribute" syntax.

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

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

This is where I think you have misunderstood my position. As human
beings we have a cognitive pre-disposition to thinking in terms
of hierarchies. There are many, many ways to represent such
hierarchies syntactically - C++ programs, SGML, S-Expressions,
tortuously inter-linked relational database tables, CODASYL,
STEP and of course XML.

They are all basically syntactic sugar. The hierarchy exists
independently of any syntactic form used to give it a digital
rather than cognitive form. XML has a nice simple syntactic
representation for hierarchies. It uses certainly terminology
to do that - elements and attributes. This terminology leads
naturally to an API for hierarchies that uses terms like:

	startElement
	attributeList
and so on.

This API is all you need to process arbitrary hierachies
of data. It is *not* a pre-condition of programming
to this API that the data must have been previously
serialized in XML notation!

Earlier in talking about "IsNess" you say:

>There is NO XML 

This is exactly my point! XML is syntax for representing
a hierarchy. This syntax leads naturally to an API
that is couched in terms of elements/attributes. This
API is the key. You do not *need* to serialize data
to XML syntax in order to use this API.
>
>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.
>

I see it as a trivial transformation to convert a
hierarcy of elements and attributes into a
collection of objects with associated instance
variables.

I believe this has been done on
numerous occasions in the SGML world. I think
it was Bob duCharme who wrote a paper about
transforming SGML instances into object hierarcies
using Smalltalk as the implementation language.

Some time ago, I prototyped an algorithm to do it
in Python but I never got around to implementing
it because I never saw the benefit of it for
my work. Having said that, I do not work with
STEP or CAD system data where I guess such
a model transformation would be more useful.

[...]
>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.

But this transformation is trivial! I guess I am having
difficult seeing why I need to employ the vast edifice
of abstraction that is the "grove paradigm" in order
to do this.


Somewhere along the line someone seems to have had
an "Aha!" moment which went like this
	"...ergo we need groves".

It is the "..." bit that I do not see.

regards,



<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
<uri>http://www.www9.org</uri>
</Sean>



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;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)