Re: SAX 2.0 enhancement proposal

[David Brownell <david-b@pacbell.net>]

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

Seems to me THAT is the problem, not SAX.

The XML spec is quite explicit on this topic:  "relative URIs are relative to the
location of the resource within which the entity declaration occurs" (4.2.2).

Those are the only contexts in which an XML parser needs to resolve URIs,
and there's no weasel-wording that would allow what that catalog spec is
intending to do.  So I don't see why SAX should permit anything else,
unless the XML spec gets a substantive functional change there ...


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

Relative URIs are, classically, trouble.  They're very easily mis-understood,
since implicit context is easy to get wrong.  Why is this catalog draft trying
to encourage/facilitate error-prone and complex idioms?  Which, moreover,
are intended to violate the XML specification?

I can understand that applications may want to define other rules for
resolving relative URIs found in application data; that's their privilege.
"xml:base" will presumably go to REC and support such usage.  So
resolvers used in those contexts may want different APIs than the
one used by an XML parser, even beyond config/setup issues.

(I vaguely recall that SGML, or at least SOCAT, may have taken a
different approach than XML has, in this respect.  That doesn't seem
to me like a good thing to try carrying forward, if so.  There were some
web-naive notions I remember not liking in SOCAT; they weren't
essential, and hence are better removed.)

- Dave