[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: "W. Eliot Kimber" <eliot@i...>
• To: "Anders W. Tell" <anderst@t...>
• Date: Sat, 25 Sep 1999 10:51:59 -0500

"Anders W. Tell" wrote:
> 
> Like many others have I started to look at the Grooves model once more
> and this time at little closer. Im especially interested in how my
> current "DOM-compliant" model matches the Groove.
> One aspect got my attention and it was that properties and not nodes
> contains "data" such as strings,integer,etc.
> 
> Could somone explain the design rationale why properties and not node
> carries data ?
> Does this design imply that tree-algorithms are easier to implement ?
> Any other aspects that benefits from this design ?

As Steve said, a node is just a set of properties. In the generic sense,
the "data" of the node is simply the union of its property values.

However, in many processing environments, and certainly in an SGML/XML
environment, it is useful to distinguish properties that are
semantically data from properties that are not data. In XML, for
example, we tend to think of the content of an element or the value of
an attribute as its "data" and ignore the other properties for most
purposes (we would not, for example, normally think of the element's
attributes as part of its data in this sense, although of course they
are in the more generic sense of the term "data").

The grove design thus augments a more generic graph of nodes data model
by letting you identify one property of a node class as being the quote
data property unquote. That is, the property identified as the data
property is the property that, semantically, holds the primary data
value for the node.  You are not required to do this for any node
class--it is just a convenience.  This is roughly analogous to default
properties in VB or __str__() and __repr__() methods in Python.

While the grove design does not specify an API for grove access (it
probably should, but we could only do so much in the time we had), the
fact that you can designate a "data" property implies a generic "data()"
method for all nodes, such that when you ask for a node's data you'll
get the value of the property designated as its data property. If you
look in the DSSSL standard, for example, you'll find a data() function
that returns the value of the data property of a node (as explained
below). Likewise, in GroveMinder's API, every node has a data() method.

For example, the attribute assignment node has two unique properties:
name and value. In the SGML property set, the property named "value" is
designated as the data property. This reflects the fact that most uses
of attributes care about the data specified as the attribute value and
thus optimizes access to it. 

Data properties must be non-nodal, that is, their allowed data type must
be one of the principal data types, such as string, integer, etc.

The grove design also augments the basic graph of nodes data model with
a "content" property. Content properties are nodal properties that
semantically contain the "content" of the node class. Like data
properties, the content property optimizes access to that part of the
grove that the grove schema designer considers to be the "content". It
implies a "content()" method that will return the value of whatever
property has been designated as the content property (if any).  Like
data properties, you are not required to designate a content
property--it is just a convenience feature.

In the SGML property set, the root of the grove is the SGML document
node. The SGML document node has a number of properties. The
DocumentElement property is designated as the "content" property so that
when you ask for the content of an SGML document you'll get the document
element, which the SGML standard says is, semantically, the content of a
document.

The implicit data and content methods are applied recursively. If you
ask for the data of a node that has a content property, the result is
the concatenation of the data properties of the subnodes of the starting
node, recursively.  Thus, if you ask for the data property of an SGML
document node, you'll get the concatenation of the data properties of
the leaf nodes of the subtree rooted at the document element. The SGML
property set has been designed so that this will be the concatenation of
the data characters in element content (and not, for example, attribute
values as well).

To sum up: the concepts of "data" and "content" properties simply
provide tools to property set (grove schema) designers to provide
convenience features to users of those groves for access to the
"semantic" content and data of the nodes.

Cheers,

E.

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: "Anders W. Tell" <anderst@t...>

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

• Prev by Date: Re: Grooves: why are "data" designed as properties and not nodes ?
• Next by Date: unsubscribe XML-DEV
• 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