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

Paul Prescod paul at prescod.net
Mon Sep 27 05:47:02 BST 1999


In your description you've renamed "values" as "leaf nodes." I don't
think that that changes the model much. It's like the distinction
between Python and Java. Java has "basic types" and "objects". Python
says some objects are built-in types and others are based on
user-defined classes. In practice the difference is small.

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

I think it comes down to the same thing that it does in a programming
language or in SQL. If the thing you need to model can be expressed as a
basic type then you do so. Otherwise you invent a new node type.

Does that hep?

 Paul

Anders W. Tell wrote:
> 
> Thanks for the clarifications, I think Im getting a feel for how groves
> works.
> 
> 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,
> LeafNodeClasses
> * NodeClasses are described by Schemas (PropertySets)
> * NodeClasses are described by the Properties it may exhibit.
> * Node instances of LeafClasses exhibit no properties except intrinsic
> properties
> * 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
> datatypes)
> 
> 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
> without
> violate the grove specification (if "declared datatype" is intepreted as
> class).
> 
> 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.
> 
> Regards
> /Anders
> /_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> /  Financial Toolsmiths AB  /
> /  Anders W. Tell           /
> /_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> 
> 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)

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)





More information about the Xml-dev mailing list