Matthew Gertner matthewg at
Tue Jan 6 13:40:49 GMT 1998

I am frankly amazed at how productive this discussion has been up to this
point, which is a good argument for maintaining simplicity in the interface.
(I also find myself wondering whether it would *really* make such a big
difference to add a callback for comments...) This initiative only started a
couple of weeks ago, and it seems to me that the preliminary spec is
essentially completed (keeping in mind that it is never going to please
everyone). The focus on simplicity has been essential.

Nevertheless, your comment on DOM building is spot on. I would love to see a
general consensus that the SAX interface be used as the basis for a more
extensive one (AAX?) providing all information necessary to build a DOM
(well, actually a DO...). One of the lovely things about object orientation
is that the SAX interface can be left as-is and still be reused for an
interface providing more functionality. I would strongly argue this point
because the central implication of SAX (i.e. that "competition" among parser
writers, rendered feasible by interoperability, will lead to higher quality,
more capable parsers) is something that we (as repository vendors) would
like to benefit from too. For obvious reasons, SAX is useless to us right

I am a strong believer in not putting the cart before the horse, so the
focus on finishing SAX seems exactly right to me. Nevertheless, it would no
doubt make it easier to finalize the SAX specification if there is some
general consensus on this. My suggestion would be:

SAX - for capturing logical structure
AAX - for capturing logical and physical structure. Sufficient functionality
to build a document object as specified by the DOM.



-----Original Message-----
From: David Ornstein <davido at>
To: xml-dev Mailing List <xml-dev at>
Date: Monday, January 05, 1998 7:13 PM
Subject: SAX: anti-goals

>Hello all,
>In the ongoing design discussion we've been having, it seems that there's a
>lack of clarity about what SAX will be used for and what it won't.  This is
>slowing down and creating confusion in some of the discussions.  While
>attempting to enumerate goals/requirements is a good idea at the start of a
>process, it can sometimes be quite difficult because people get hung up on
>being complete.  Instead, one approach I sometimes take is to define
>"anti-goals."  An anti-goal is a declaration of what one is *not* trying to
>do/support/achieve in a design.  They are not things you're trying to
>avoid, in fact some of the best anti-goals are ones that describe things
>that would be very nice to have but have agreed to place out of scope.  The
>incremental accumulation of anti-goals during a design process can help
>keep things on track.
><wry>And the list can later be used when retrospectively constructing a
>list of a project's goals.</wry>
>My read is that we seem to have a strong leaning towards the following
>* SAX is not being designed to support configurations where the parser is
>in one language and the client is in a different language
>* SAX is not being designed to support identity transformations of an XML
>document('s physical structure)
>* SAX is not being designed to be usable in building a DOM tree [Actually,
>my personal suspicion is that this one is likely to generate lots of hot
>Do others agree/disagree with these as our anti-goals?  If so, I'd propose
>that, to help keep us (and new folks) on track, they be included in any
>summaries of the SAX work we put out.
><note>I don't necessarily like all of these goals, personally, as they
>reduce SAX's utility for me.  I'm just suggesting that  they do seem to
>where we're heading.</note>
>David Ornstein
>Pragmatica, Inc.
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
>Archived as:
>To (un)subscribe, mailto:majordomo at the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo at the following
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list