Announcement: SAX2 1999-06-01 alpha release for Java

[David Brownell]

David Megginson wrote:
> 
> Miles Sabin writes:
> 
>  > Is there any chance of us changing that? How about an
>  > alternative start tag reporting interface which reports,
>  >
>  >   startOpenElement(String name);
>  >   startAttribute(String name);
>  >   attributeCharacters(char[] chars, int off, int len);
>  >   endAttribute(String name);
>  >   endOpenElement(String name);
> 
> The trouble is that this would benefit relatively few people and make
> life harder for all the rest.  

Right.  Making an extra 2 (+3x #attributes) invocations per
element could also be a performance issue of no small note!


Miles -- you're on the right track re using the extension
mechanism for this functionality.  What'd be needed is parsers
which would use it... I think that the API calls you sketched
above might do the job, maybe even within the DTD.  (I have
no interest in exposing parameter entity handling, FWIW!)


>		The more we discuss these issues, the
> more I think that SAX shouldn't try to be all things to all people --

Being all things to all people is a bad idea ... and frankly,
supporting every dubious DOM feature (notably entity boundaries
and the wrong level of DTD support ;-) isn't so good either.


> perhaps we should let the 'S' continue to stand for 'Simple', and
> target only the 80% (or 98%, more likely) who care mainly about the
> Holy Trinity of elements, attributes, and character data.

SAX 1.0 is good job what it does:  that "Trinity".  To be honest,
I think it's more at the 80% level, since it doesn't let programs
know basic parser characteristics (validation, external entity
handling, ignorable whitespace reporting, etc).  They need that
to really support swapping one parser out for another.

	** Hmm, I think another SAX 2 "feature" flag would be
	** useful for whitespace  ... applications can be confused
	** if they expect "ignorable" whitespace to be ignored,
	** and the parser doesn't report it!

What SAX 2.0 needs to do, IMHO, is fill in the holes in 1.0 (like
exposing those characteristics) and support some of the growth in
XML applications, as well as to provide a standard framework for
the inevitable extensions so application architectures don't get
too crazy-looking.  I think it does so reasonably now, modulo the
issues I've noted.

Re those inevitable extensions ... I think standardizing the way
DTD information shows up is useful, not just to support DOM but
also since there are lots of folk who'd like DTDs to constrain what
changes are made.  (There's a "wait-and-see" for schemas.)

Similarly, XHTML will become more significant ... and so I think
exposing comments (which often wrap inline CSS and scripting) is
also good to standardize.

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)