[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

• From: "Anders W. Tell" <anderst@t...>
• To: xml-dev@i...
• Date: Sun, 26 Sep 1999 15:23:33 +0200

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

• Follow-Ups:
  • Re: Grooves: why are "data" designed as properties and not nodes ?
    • From: Paul Prescod <paul@p...>
  • Re: Grooves: why are "data" designed as properties and not nodes ?
    • From: Ken MacLeod <ken@b...>

• References:
  • Grooves: why are "data" designed as properties and not nodes ?
    • From: "Anders W. Tell" <anderst@t...>
  • Re: Grooves: why are "data" designed as properties and not nodes ?
    • From: "W. Eliot Kimber" <eliot@i...>

• Prev by Date: RE: RFC: Attributes and XML-RPC
• Next by Date: Re: Grooves: why are "data" designed as properties and not nodes ?
• Previous by thread: Re: Grooves: why are "data" designed as properties and not nodes ?
• Next by thread: Re: Grooves: why are "data" designed as properties and not nodes ?
• Index(es):
  • Date
  • Thread