[
Lists Home |
Date Index |
Thread Index
]
- From: Matthew Gertner <matthew@praxis.cz>
- To: "Steven R. Newcomb" <srn@techno.com>
- Date: Fri, 24 Sep 1999 17:57:21 -0400
> I don't think there's anything really new in groves, except possibly
> the (admittedly terrible) GROVE acronym itself. How would you model
> the thing that groves model? Remember the requirements: it has to be
> a machine-processable formal model, and it has to cover the whole
> territory of information resources, not just XML resources, and make
> every component addressable.
Total agreement that the grove concept, while nothing earthshattering,
has tremendous value as a standard because of the possibility to
leverage abstract implementations over a wide variety of problem
domains. Being able to identity that something is a subnode and not an
external reference (through the node relationship type) or that subnodes
are children and not just any old node list (through the children
property name) is very cool and useful. What I don't understand (among
many other things) is how this is extended. You comment that HyTime
provides all the functionality of RDF and then some. How much of this
comes from the underlying use of groves? RDF lets me define arbitrary
property types that can be standardized and leveraged across
applications (like the Dublin Core). I can do this with a particular
property set, but can I do it across *all* properties sets? Can I
somehow say (either by creating new intrinsic property types or new node
relationship types) that a given node property value is a "creator"? If
not, what does HyTime bring to the party and wouldn't it be better to
provide these capabilities on the generic property set level?
(BTW: I have to make a big plug for Paul Prescod's July99 grove
tutorial. After reading this I *finally* feel like I understand what the
#%@$! a grove is. Great work Paul! If you are trying to understand
groves without reading this, don't torture yourself.)
> And what were those "good reasons" for which groves and HyTime
> "failed"? It looks to me like the primary reasons for HyTime's lack
> of mass acceptance, to date, have been the lack of a general toolkit
> implementation, and public ignorance of the problem space in which
> HyTime offers solutions.
Well, yes, but another problem IMHO is that HyTime throws out too many
hard-to-understand concepts at once. The linking model is hard to
understand. Groves are hard to understand. Architectural forms are hard
to understand. Throwing these together in a 1000 page document is not a
recipe for commercial success. It seems to be an unambiguously good
thing that these concepts are now being split into bite-sized chunks in
the process of transfering them into an XML context.
Matt
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|