xml-dev - Re: SAX2: relative ordering of startDocument() & startDTD() events?

[Michael Fuller <msf@io.mds.rmit.edu.au>]

David M. wrote:
> <warning target="everyone" level="severe">
>  I am not willing to let this issue hold up SAX2, because I do not
>  believe that it is important enough (a minor point for an optional
>  add-on handler that few sane users should care about).  
> </warning>
> 
> That means that when SAX2/Java goes to final (there'll be at least one
> more beta first), it may have a broken LexicalHandler or even no
> LexicalHandler if necessary.  It may also be that the optional
> handlers simply don't get bundled in the main SAX2 distribution.

This, to my mind, would be a Bad Thing.
Any application that needs to act in a parser-like fashion *needs* some
of LexicalHandler.

For example, how do you write an XSLT engine with a SAX interface
if you can't see and can't generate comments?

If you want to pipeline parsing-applications, how can you do that
if you can't see what DTD name/PUBLIC/SYSTEM identifier applies,
or tell a recipient? Likewise, marked CDATA sections?

If you want to use SAX as an interface to an editor, say,
how do you keep track of external entity references?
Or, if you have a SAX processing pipeline, are you forced
to suck all entities in at stage 1?

Personally, I would have advocated folding this sort of functionality
into the new ContentHandler; I never pushed that because it doesn't seem
to be what the consensus wants. However, to be dropping or even just
delaying the LexicalHandler really concerns me.

(If we're running low on time, I suggest we retrospectively un-waste
the time we spent arguing over string interning... :-)

So. Question. What do we need to do to get LexicalHandler to completion in
an acceptable timeframe? Anyone care to explicitly describe the problems
that need to be resolved? (I'm not completely clear what they are myself.)
If we can do that, then perhaps we will be able to identify what is definitely,
possibly, and unlikely to be included, and formulate an interface.

Michael

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************