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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Why SAX doesn't have a requirements document (was Re: ModSAX (SAX 1.1) P

[ Lists Home | Date Index | Thread Index ]
  • From: David Megginson <david@megginson.com>
  • To: "XML Developers' List" <xml-dev@ic.ac.uk>
  • Date: Wed, 17 Feb 1999 09:26:14 -0500 (EST)

Clark Evans writes:

 > I think it would be better to start with Requirements, then some
 > Analysis instead of jumping straight to Design.

[snip]

 > Some of these are a bit far-out, but it's hard to know what the
 > "specific goals" of SAX 1.1 are.

They are mostly the same as the goals of SAX 1.1:

1. Keep the interface absolutely minimalist -- anything that can be
   implemented on top of SAX rather than inside it doesn't belong in the
   core interface.

2. Avoid dictating design decisions to parser writers to the greatest
   degree possible.

To these, I would add #3 for version 1.1:

3. Provide a standard, dependable mechanism for people to supply
   extensions. 

 > Thus, some type of requirement document followed by perhaps some
 > use cases would be illustrative.

This is a very wise suggestion, but I will decline to take it up --
the real reason for requirements documents, design documents, etc. is
to provide a paper trail for protection against political in-fighting,
and we're all much too partical and friendly on XML-Dev to need that
sort of thing.

In practice too much overhead simply distracts from rapid development
and deployment.  There are tens of thousands of pages of unused ISO
and even W3C specs gathering cyberdust despite the fact that
incredibly large numbers person-days went into designing requirements,
use cases, etc. -- all the process did was help to keep people busy,
but none of it helped ensure guaranteed (in fact, the process almost
always made things worse, because too many hypothetical requirements
and use cases tend to bloat the specs to the point that they're not
worth implementing).

SAX 1.0 succeeded because we kept it small and finished it quickly
(and thus, hit a critical window in the market) and because I shipped
it with working code (SAX drivers for the four XML parsers).  This is
a design phenomenon well-known to all of us on a much larger scale
with the success of HTML -- sure, HTML compatibility in browsers is a
bit of a mess, but if Tim B-L had gone through a formal collaborative
design process ten years ago, HTML probably wouldn't exist at all
today (except possibly as yet another historical footnote in HyperText
papers).


All the best,


David

-- 
David Megginson                 david@megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto: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