[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Announcement: SAX Java Implementation (pre-release)

• From: David Megginson <ak117@f...>
• To: "xml-dev Mailing List" <xml-dev@i...>
• Date: Tue, 14 Apr 1998 14:04:02 -0400

Michael Kay writes:

 > >I have put together a new, beta version of SAX with quite a few
 > >changes; here are some change highlights...
 > 
 > Only one technical comment: if we allow a character stream
 > to be passed to the parser as the primary input, it does seem
 > inconsistent that resolveEntity() cannot return a character stream
 > for other entities, e.g. the DTD. (In fact, if resolveEntity() could return
 > a stream/reader, one could rely on this to provide a stream/reader
 > for the primary input as well, simplifying the main parse() interface).

This is trivial in Java (where you could simply check the type of the
returned object), but quite complicated in languages that lack dynamic
typing.  The only way to handle this in a language-independent way
would be to introduce Yet Another Class to SAX:

  public abstract class SAXInputSource {
    public final static int SYSTEM_ID = 1;
    public final static int CHARACTER_STREAM = 2;

    public abstract int getType();
    public abstract String getSystemId();
    public abstract SAXCharacterStream getCharacterStream();
  }

I'm actually wondering how badly we need the SAXEntityResolver at all
-- it seems to me that URI redirection is a very general problem that
belongs outside of SAX (say, in the system libraries or in a proxy
server).  The only real benefit right now is that SAXEntityResolver
allows an application writer to do something useful with public
identifiers.

 > Other comments are on the documentation:
 > 
 > - I think we should recommend people implementing the callback
 > handlers to subclass from the base implementation, as this allows
 > their code to remain compatible if the interface is widened in a
 > later SAX version.

For Java users, the problem is that the handler would then be unable
to inherit from anything else; in any case, I was thinking of widening
the interface by extension, not by modification.

 > - The specifications tend to say "you" when they mean the application
 > writer, and "the parser" when they mean the parser writer. It would be
 > useful to spell out the roles more clearly (call them the parser and the
 > application) and make it very clear for each interface whether it is
 > supplied by the parser or by the application.

This is an excellent point -- I will add it to my TODO list.


Thanks, and all the best,


David

-- 
David Megginson                 ak117@f...
Microstar Software Ltd.         dmeggins@m...
      http://home.sprynet.com/sprynet/dmeggins/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• References:
  • Re: Announcement: SAX Java Implementation (pre-release)
    • From: "Michael Kay" <M.H.Kay@e...>

• Prev by Date: Re: Problems parsing XML
• Next by Date: possibility of an RTF, LaTex XML conversion process (fwd)
• Previous by thread: Re: Netscape XML Newsgroup
• Next by thread: XLINK discussion
• Index(es):
  • Date
  • Thread