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

[David Brownell]

David Megginson wrote:
> 
> 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?

SAX1 specifies explicitly that the handlers can be changed mid-parse;
see your spec for the "org.xml.sax.Parser" class!  :-)  


>  >      - 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.

I'd vote to scrap them, then.


>  >      - 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.

... and 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.

True ... but if those start/end events get dropped, then I'd ask
to get a callback with the literal text of the internal subset.


>  >      - 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.


OK, next step for me then would seem to be more code actually _using_ the
new SAX2 APIs!

- Dave

> All the best,
> 
> David
>

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)