Grooves: why are "data" designed as properties and not nodes ?

Anders W. Tell anderst at
Sun Sep 26 15:24:12 BST 1999

Thanks for the clarifications, I think Im getting a feel for how groves

However my initial question remains, why are "data" located in properties
and not nodes.

If actual "data" where to be moved into Nodes the Grove model would still be
well defined
and maybe even simpler to understand and work with.
A alternative definition would be something like this:

* A Grove instance consists of Nodes and Properties.
* A Property is a directed and named relation between Nodes.
* A Property relates a single Node to one or more Nodes (nodelist)
* Nodes are instances of a NodeClass
* NodeClasses fall into two broad categories, ContainerNodeClasses,
* NodeClasses are described by Schemas (PropertySets)
* NodeClasses are described by the Properties it may exhibit.
* Node instances of LeafClasses exhibit no properties except intrinsic
* LeafNodes exhibit a value according to its class. Types of values are
integer's, string,float ,etc.
* ... intrinsic property ... data property ...
* ... intrinsic property ... content property ...
* ... groove plan ...

In this definition the "data" is folded into the same type system as Nodes.
(in the Grove definition there are two type systems, classes and declared

I also found an interesting sentence in the A.4 Property Set Definition
Requirements (PSDR)
document in section A.4.1.2:
A property has a "declared datatype" which specifies the type of value nodes
are permitted to
exhibit for the property.

So maybe I can interpret/implement Property *value nodes* a Nodes anyway
violate the grove specification (if "declared datatype" is intepreted as

What Im really trying to find out is if the choice of putting "data" in
properties or nodes
is a "coin toss" desision or if there are any theoretical or practical
reasons to select
either design.

/  Financial Toolsmiths AB  /
/  Anders W. Tell           /

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list