OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: XML Grove Plan

[ Lists Home | Date Index | Thread Index ]
  • From: "W. Eliot Kimber" <eliot@isogen.com>
  • To: xml-dev@ic.ac.uk
  • Date: Sat, 13 Sep 1997 15:15:07 -0500

Note that a grove plan is not a property set: a grove plan is simply a
statement of which classes and properties are included in the property set
used by a particular processor or process.  For example, the HyTime default
grove plan is:

<grovplan propset=SGMLProp id=htdefgp>
<title>HyTime Default SGML Grove Plan</title>
Removes processing instructions (pi) from and
adds pseudo-elements (pelement) to the default SGML
grove plan defined in the SGML property set.

Which is itself a delta on the SGML default grove plan (indicated by the
presence of the "default" attribute on those modules, classes, and
properties included in the SGML default grove plan).

The discussion of grove plans can be found at:


At 09:44 AM 9/13/97 +0100, Sean Mc Grath wrote:
>I raised this issue a long time ago and I am delighted to see it is being
>considered for inclusion in XML. Having a grove plan gives developers
>a sanity checker for their parsers. Having a grove plan with a syntactic form
>that can be output from a parsers internal tree representation provides a
>for testing and comparing parsers. Having a grove plan allows apps to be
>that process post-parse data-structures as opposed to using an API.

There is a defined syntactic representation for *groves* (as opposed to
grove plans, which is what I think Sean meant), called the "canonical grove
representation" (CGR) document, described in

CGR documents are designed such that two groves that are identical should
produce exactly the same CGR documents, character for character.  They are
designed specifically to enable the comparison of the groves produced by
different tools, which is useful both for checking tools and for doing
comparisons of documents by comparing their CGR documents (this allows
documents to be compared meaningfully without regard to their original
markup syntax as long as the groves used for comparison do not include any
markup properties).  CGR documents are also designed to be easy to process
with text processing tools like Perl so that they can be used must as you
would use the output of NSGMLS.

I'm in the process of creating a DSSSL spec to generate CGR documents using
Jade--I'll post something about it to comp.text.sgml when I get it working.



xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS