SAX: External Entity Resolution (question 3 of 10)

[David Megginson]

[SAX is a proposal for a simple, event-based XML API, using
callbacks.  This is one in a series of ten design questions that we
need to answer to implement the API.]

Should SAX provide a handler for resolving external entities?

  public String resolveEntity (String ename, String publicID, String systemID);

The handler would receive the system identifier, optionally
accompanied by an entity name and public identifier if available, and
would return the system identifier (URI) that the parser should use
for the entity, or null if the entity should be skipped.


CON
---

- makes the API slightly larger;

- requires modification to existing parsers -- cannot be supported
  simply with a new front-end;

- deals with physical rather than logical structure;

- a local proxy server could implement much of the same functionality;

- could be confusing for non-specialists.


PRO
---

- could be implemented in XmlAppBase, so that most users could simply
  ignore it (the default implementation would always return the
  systemID argument unmodified);
 
- allows redirection of URIs to local copies, if available (and to
  other protocols);

- allows resolution of public identifiers using a table lookup;

- allows a user to skip external entities if they are not necessary or
  desirable (if, for instance, they outside of the company LAN, or if
  they require payment for use).


MY RECOMMENDATION
-----------------

Undecided: no recommendation.

If there is a default implementation hidden in XmlAppBase, then most
users can simply ignore this method and rely on the default
behaviour.  This is a very simple and very powerful tool, especially
for people with limited or no outside Internet access, or for people
working in secure environments.  Much of this could also be done with
proxy servers, of course, but that is a solution more for companies
than for individuals.

The problem is that most parsers don't support this functionality
right now, so we could not simply implement a new SAX front-end on top
of the parser's existing API.  On the other hand, we could make
support for this optional, and add an entityResolutionSupported()
boolean call to the XmlParser interface (see question 9, to be posted
later).



All the best,


David

-- 
David Megginson                 ak117 at freenet.carleton.ca
Microstar Software Ltd.         dmeggins at microstar.com
      http://home.sprynet.com/sprynet/dmeggins/

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/
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)