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

[Anders W. Tell]

"Steven R. Newcomb" wrote:

> [Anders W. Tell:]
> * The SGML Property Set, which is an instance of a property set as
>   defined by the grove paradigm, is somewhat comparable to the DOM.
>   The DOM is not directly comparable to the grove paradigm.  Maybe
>   your current "DOM-compliant" model is comparable to the grove
>   paradigm, though (depending on what it is).

Yes almost, however the nodes are values, simple or constructed.

> > Could somone explain the design rationale why properties and not node
> > carries data ?
>
> Properties do not "contain" data.  Properties are like variables: they
> can "have" values.
>
> A node *consists* of a set of named properties and their values, if
> any.  A node (an instance of a class of nodes) can have many
> properties.  Some properties are "data" properties; this means that,
> unlike "nodal" properties, their values must be data, and cannot be
> nodes.  If nodes were the same thing as data, or if nodes could be
> treated as data, then they would have only one property, whose value
> would be the data.  That would not be as useful as having nodes
> consisting of any number of named properties, any number of which can
> be data properties.

So if I understand it correctly, when Propertys have values then Nodes are *multi-valued*
which differes from the case when nodes are values themselfs.

An example how this design might be used:
Serialization of a programming language "Object"

Freeform PropertySet: "Objects"
----------------------------------
NodeClass: "ProgObject"
  Properties:
     "Members": NodeList , restricted to Nodes of class "ProgMember"

NodeClass: "ProgMember"
   Properties:
      "c++-type" : string
      "c++-value" : any property type, restricted to the "c++-type" types of values
      "visualbasic-type" : string
      "visualbasic-value" : any property type, restricted to the "visualbasic+-type" types of
values

And if I want to treat this Grove as C++ Object then I apply a Grove-plan which
"filters" out all "visualbasic-x" properties or keeps the "c++-X" properties.


> > Does this design imply that tree-algorithms are easier to implement ?
>
> The design of the grove paradigm is explicitly intended not to imply
> anything at all about implementation.

Ok, but what about algorithms that uses the Grove?
(how Information is organized does affect algorithms
even if the "organization" is generic.)

/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)