SAX 2.0 enhancement proposal

[Rob Lugt <roblugt@elcel.com>]

With the work being performed by the OASIS Entity Resolution TC [1],
attention is being focused on resolving entities using XML Catalogs.  An
obvious way to implement catalog processing is by providing a custom SAX
EntityResolver.  However, the SAX 2.0 specification [2] puts an impediment
in the way of a conforming implementation.  I'll explain why...

The XML Catalog draft specification [3] describes several different entry
types.  Some entries are for resolving public identifiers, some are for
resolving system identifiers.  The system identifier entries are intended to
be matched with the system identifier as it appears in the xml document
being processed.  Unfortunately, SAX 2.0 requires that system identifiers
that are URIs are made absolute before calling the EntityResolver, thereby
robbing the catalog processor of the opportunity to compare the system
identifier with the catalog entries.

In my view, an improved EntityResolver interface (perhaps for SAX 3.0) would
be :

interface EntityResolver
{
    public InputSource resolveEntity(java.lang.String name,
                                                         java.lang.String
publicId,
                                                         java.lang.String
systemId,
                                                         java.lang.String
baseUri)
    throws SAXException, java.io.IOException;
}

This would give the EntityResolver everything it needs to do the job.  If it
wanted to absolutize the system identifier then it could do so, but it would
also have access to the bare value.

Of course I realise that this is not practical for SAX 2.0, and we don't
want to wait for SAX 3.0 before implementing conforming and portable XML
Catalog processors under SAX.  I propose a simple extension to SAX 2.0 in
the guise of a new standard feature:
http://xml.org/sax/features/absolutize-system-identifiers.  The default
value could be "true" to maintain compatibility with existing systems.
Applications could set it to "false" when they want a conforming catalog
processor.

Anybody agree, disagree or indifferent?

Regards
Rob Lugt
ElCel Technology
http://www.elcel.com/

[1] http://www.oasis-open.org/committees/entity/
[2] http://www.megginson.com/SAX/Java/javadoc/index.html
[3] http://www.oasis-open.org/committees/entity/spec-2001-06-12.html