xml-dev - groves vs. Groves was: Re: Why the Infoset?

[Jonathan Borden <jborden@mediaone.net>]

Simon St.Laurent wrote:

> At 03:29 PM 8/2/00 -0500, Bullard, Claude L (Len) wrote:
> >""Groves are the greatest thing I've
> > never seen or completely understood."
> >
> >with the possible exception of Architectural Forms."
>
> That doesn't imply not invented here - it merely implied never seen in
use.
>
> >The work invested in groves by others
> >seems to indicate they may be appropriate
> >for defining subsets.

First, I think we are having a problem with terminology. There are "groves"
and "property sets" the concepts, and "Groves" and "Property Sets" the ISO
specifications (e.g. SGML, HyTime and DSSL)Let us all agree on standard
terminology and definitions. I will quote Charles Goldfarb
(http://www.oasis-open.org/cover/grove-CFG.html)

">Sorry to be so unaware, but just what is a "grove plan"?

This answer is informal; the formal stuff can be found in the DSSSL standard
and
the forthcoming HyTime TC. It's also compressed, so read it slowly.

A parsed SGML document is usually called a tree. Actually, it can be a
collection of trees because the value of an attribute, for example, can be a
tree and that tree isn't a "child" of the element. The DSSSL, HyTime, and
SGML97
standards call that collection a "grove".

The set of things that a notation such as SGML can represent is called its
"property set". The property set governs the construction of the grove when
an
object conforming to the notation is parsed. A grove that includes every
object
class and property defined in the property set is called a "complete grove."
For
SGML, that would not only include the abstract information (the ESIS), but
also
information about the original markup.

Since not every application will need to deal with a complete grove, a
"grove
plan" can be specified that will limit the object classes and properties
that
will appear in the grove. For example, you could choose to include comments
and
PIs in an SGML grove plan, or you could omit them. It is possible for user
or
vendor groups to define useful grove plans for interworking. (ESIS would be
an
example of such a grove plan.)
"

Now that we agree :-) on what a grove, property set and grove plan is, we
can easily see that the XML Infoset is indeed a "grove plan" of the abstract
XML grove. But it is not a "Grove Plan" of the "XML Property Set" in the ISO
sense.


>
> The alternative, which you seem bent on ignoring, is expanding the list of
> information items to include more of XML's features.  I could probably
live
> with getting back items 1, 2, and 8 from the list in Appendix C:
> http://www.w3.org/TR/xml-infoset#omitted
>
> 4, 9, and 10 are also intriguing, and there may be those who'd like the
> entire list back.  Some general discussion of which whitespace is
> considered significant might also be worthwhile.
>
> No groves, but not exactly a revolution either.  It'd be a change to those
> who consider DTDs throwaways, mysteriously burned away during parsing, but
> that's about it.
>
    Yes little "g" groves. Yes little "p" property sets. The real question
is how to specify "property sets". Ought we use the ISO definitions, or
revisit the issue.

Let me rephrase your objection: You are (correctly) objecting to the
development of an XML grove plan (XML Infoset) in the absense of the
specification of the XML property set.

What we need is a common language for the specification of XML subsets
(grove plans), from the full fidelity XML property set. This would place the
Infoset, Common XML and SML within the same framework so we can have a
rational discussion of the issues. Change the terms, I could care less, but
you all know what I mean.

Jonathan Borden
The Open Healthcare Group
http://www.openhealth.org