Announcement: SAX2 1999-06-01 alpha release for Java
David Megginson
david at megginson.com
Wed Jun 16 15:45:28 BST 1999
David Brownell writes:
> - I think the "validation" property should be immutable during
> parses; nonvalidating parses will generally discard data
> that a validating parse requires.
Agreed.
> - Why shouldn't declaration and lexical handlers be set "at any
> time" during a parse, like the SAX1 handlers?
Is this the case with SAX1, or is it simply underspecified?
> - 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.
I'm either to live with the status quo or to back out and scrap
reporting of entity boundaries altogether -- this is getting far too
complicated for far too little real reward.
> - 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.
Ditto.
> 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.
Agreed -- this needs to be fixed somehow.
> - 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 internal subset is available, indirectly -- it consists of
everything between the start/endDTD events outside of any
start/endEntity events.
> - The SAX1 handlers aren't "gettable" in the way the SAX2 ones are.
> Suggested fix: just define handler IDs for them.
That's a good idea.
All the best,
David
--
David Megginson david at megginson.com
http://www.megginson.com/
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)
More information about the Xml-dev
mailing list