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

[David Brownell]

>   http://www.megginson.com/SAX/SAX2/

I thought I'd pass on some comments from having implemented to this API.
(Does anyone have "user" comments yet?)

    Issues with what's now in the draft API:

	- I think the "validation" property should be immutable during
	  parses; nonvalidating parses will generally discard data
	  that a validating parse requires.

	- Why shouldn't declaration and lexical handlers be set "at any
	  time" during a parse, like the SAX1 handlers?

	- When I implemented reporting of entity expansion for Sun last
	  fall, I ran into a problem case that hasn't been addressed in
	  the SAX2 draft.  Namely, entities in attributes ... consider
	
		<element attr="&entity;"/>

	  will generally get reported as
	
		startEntity ("entity");
		endEntity ("entity");
		startElement ("element", {"attr", value-of-entity, ...} ...);
		endElement ("element");

	  which doesn't really make sense.  Sun's parser deals with this
	  issue by not reporting such entity expansions.  It's not clear
	  to me how SAX2 will deal with the issue.

	- There's a similar issue with expanding parameter entities:

		<!ATTLIST element
			%common-attrs;
			%i18n-attrs;
			%optional-attrs;
			attr NOTATION ( %notation-set-1; ) "fubar"
			>

	  And so on with conditional sections and other declarations; Sun's
	  parser deals with that issue by not reporting parameter entity
	  expansions through those reporting callbacks.

    Issues with what's NOT in the draft API, and where the lack is IMHO a
    notable API completeness issue for a "core" in SAX2:

	- Information re NOTATION attributes is discarded.  In the example
	  above, the attributeDecl() callback discards the list of which
	  notations are permitted.  Suggested fix:  update the API.  Sun's
	  API doesn't discard this info, others are also possible.

	- The internal DTD subset isn't available.  This means one can't
	  reproduce the <!DOCTYPE...> declaration; some applications have
	  convinnced me that they absolutely require that capability.
	  Suggested fix:  as above, update the API (look at Sun's for one
	  solution known to work).

	- The SAX1 handlers aren't "gettable" in the way the SAX2 ones are.
	  Suggested fix:  just define handler IDs for them.

I thought I'd pass these along, since I've not seen much other feedback
that relates to SAX2 implementation issues.

- Dave

p.s.  http://home.pacbell.net/david-b/xml/ for the adapter I did to Sun's
	parsers.

	With those and AElfred, I think folk have a pretty good basis to
	experiment with validating and nonvalidating XML parsers (and an
	HTML parser!) to get some user experience with these APIs.

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)