Simple approaches to XML implementation

[Peter Newcomb]

> From: "Peter S. Housel" <housel at ms7.hinet.net>
> Date: Wed, 5 Mar 1997 00:05:30 +0800
> 
> Here's what I'm looking for in an XML/SGML API.
> 
> First I want an entry point that allows the application to query
> the parser implementation what property set modules it supports
> (i.e., what's the richest grove plan available to users), and whether
> or not validation is available.

This should be implemented both as a set of API methods (for tightly
coupled applications) and as a machine-readable (SGML) system
declaration document (for remote and/or code-incompatible
applications), and (for SGML/HyTime systems) I think should also
include information about what storage managers, architecture engines,
and other notation processors (for multimedia addressing) are
available.

> Next, there should be an XMLEventStream object.  To create an
> XMLEventStream, you specify:
> 
> 1. The URL of the document to open.
> 2. The grove plan you want, in the form of a list of property set modules.
> 3. Whether or not you want validation done.
> 
> This gives a stream-based interface to the XML document.  By default, the
> grove plan would be {baseabs, prlgabs0, instabs}, which gives you a stream
> of XMLEvent objecs that corresponds almost exactly to ESIS.
> 
> If you ask for more modules than that, XMLEventStream will give you
> a richer set of objects, a stream including such things as the
> contents of the DTD, comments, or whatever you like.
> 
> As a layer above that, there should be a grove-based interface that
> takes the stream and turns it into a grove.  Once built, the grove
> can be examined using an interface similar to SDQL.  As someone has
> already noted, there should be concrete subclasses of the Node
> class, but the property-getting interface should work whether the
> property is stored in a list of properties or in a special instance
> slot.

Agreed.  However I do not think that an API specification should
dictate whether the grove is built from the event stream or the event
stream from the grove; I would regard that as an implementation issue
since some applications may choose to store documents as character
streams and others as groves (or collections of objects similar to
groves).  The important thing is that both APIs (event stream and
grove) be provided.

> I'm very fond of the idea of mapping documents of various MIME types
> onto XML documents.  The translator could work as an XMLEventStream,
> making the grove-building machinery common to all document types.
> 
> Still higher application-specific layers could be built easily.

I'm not sure exactly what you mean by "mapping documents of various
MIME types onto XML documents" though I would be interested to know.

I do believe, however, that an API designed along these lines would
make a wide variety of applications both possible and relatively easy
to implement.

> Am I way off base here?  I know this is the kind of interface that would
> make
> me happy...

What you suggest is _exactly_ in line with what I want and have been
developing.

-peter

--
Peter Newcomb                           TechnoTeacher, Inc.
233 Spruce Avenue                       P.O. Box 23795
Rochester, NY 14611-4041 USA            Rochester, New York 14692-3795 USA
+1 716 464 8696 (home)                  +1 716 464 8696 (direct)
+1 716 755 8698 (cell)                  +1 716 271 0796 (main)
+1 716 529 4304 (fax)                   +1 716 271 0129 (fax)
peter at petes-house.rochester.ny.us       peter at techno.com
http://www.petes-house.rochester.ny.us  http://www.techno.com

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