XML and groves/property sets

On December 22, Steven R. Newcomb wrote:

> I would say there's appreciable consensus about the grove paradigm.
> SP does it, JADE does it, MarkMinder does it, and the next version of
> HyMinder is about to do it.  Three international standards do it, and
> a fourth (SGML itself) will undoubtedly do it next year.  (Come to
> think of it, Fujitsu Labs put a layer over old HyMinder in order to do
> DSSSL with it.)  Alex Milowski is doing it.  Several topflight people
> are talking about doing it.  If you already have groves, it would be
> ridiculous to do any kind of hyperlinking without using the grove
> paradigm.  If we assume the use of groves and property sets for
> expressing the object model of XML documents, the anchor awareness
> question becomes "merely" one of how elaborate the relationships
> involved in hyperlinking should be.
> 
> I was asking the question from the other angle, assuming that we have
> NOT yet decided to use the grove paradigm for XML.  Without groves,
> anchor awareness is a huge headache.  I think a decision to do anchor
> awareness pretty much necessitates moving to the grove paradigm.

If anyone has responded directly to this issue, I have missed the
response in the flurry of year-end "anchor" discussions.  Yes, I
have heard that the concern for "anchor awareness" (expressed exactly
in those terms, and perhaps even the concept) is not a concern shared
by everyone.  My question has to do specifically with XML's disposition
toward groves and property sets, as explained in similar words by Eliot
Kimber on Dec 23rd:

> With the TC, HyTime processing can now be integrated with any addressing
> scheme you care to support.  All you have to do is define for the HyTime
> engine what sort of nodes you'll be returning, which you do by defining a
> property set and creating the appropriate software to provide a "grove
> view" of the data.  If you're not using a HyTime engine, then just do what
> you would have done anyway.
> 
> As I've said in other notes to this group, this should be almost trivial
> for TEI locators because they're both designed to address SGML documents
> and well documented (and implemented to some degree by at least two
> browsers).  This means that defining how TEI locators address groves, SGML
> document groves in particular, should be very straight forward, and
> adapting the existing facilities to support whatever XML needs shouldn't be
> hard (it may already be inherent in those tools' functionality).

I have heard several contributors stress "keeping it simple" for the
sake of the HTML crowd -- wishing not to put the XML spec out reach
by virtue of (using HyTime's sometimes) non-intuitive use of hypertext
terms, and such.  Fair enough.  But the points made by both Eliot and
Steve (I think) sound very worthy of the ERB's attention, and I hope
they will be addressed -- ultimately in terms of reference to the HyTime
TC, and particularly in terms of reference to groves and property sets:

(1) If the HyTime TC and SGML Extended Facilities offer a framework for
defining what we know we want/need in hypertext linking, including the
critical issue of link semantics, then it makes sense to try to
define -- at least for the benefit of *some* people, and for XML's
later versions -- XML hypertext functionality in terms of groves and
property sets.  Design for the future, not for today: "today" is
already past.

(2) If the definition of XML's hypertext facilities in terms of the
"groves and property sets" framework yields a specification that
seems too difficult for the HTML crowd to uderstand, then (a) translate
the language of that specification, defined at that higher level of
abstraction, into language that's more accessible, but (b) don't let
the difficulty of the design language tyrranize the ERB's efforts
to "get it right for the future."

I sense that some of the XML design is just too "backward looking"
because a key design goal is to keep XML "simple."  What people
are doing on the Web *today* isn't necessarily simple: it's
profoundly complex.  I agree with Len that if XML doesn't
offer an adequate framework for doing these complex things,
developers will forge ahead, as always, with proprietary ad hoc
solutions to their real problems.

Just my 2 cents...

Robin

-------------------------------------------------------------------------
Robin Cover                    Email: robin@acadcomp.sil.org
6634 Sarah Drive           
Dallas, TX  75236  USA            >>> The SGML Web Page <<<
Tel: +1 (972) 296-1783 (h)     http://www.sil.org/sgml/sgml.html
Tel: +1 (972) 708-7346 (w)
FAX: +1 (972) 708-7380
=========================================================================

Received on Saturday, 28 December 1996 12:39:34 UTC