Re: SAX 2.0 enhancement proposal

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

By the way, having skimmed the 12-June-2001 draft of that OASIS
proposal, I don't see where it said that it needs relative URIs as inputs.

Lots of text talking about use of relative URIs internal to the catalog,
but nothing about such critters as inputs to the algorithms.  That would
seem to be a problem in that draft.  (Clearly I'd say to define the inputs
as excluding relative URIs.)


Rob Lugt responded:

> Norman Walsh and Paul Grosso have posted replies that clearly indicate that
> what the XML Catalog spec is suggesting is a perfectly valid thing to do.  I
> agree with them.

On the other hand, I found their responses to be off-target.  Paul seemed
to think that I was saying that remapping was wrong (it isn't, or else web
caching couldn't work), and Norm responded as if I was talking about the
ID-to-data mapping (I wasn't).  Those parts of what that catalog draft is
talking about are fine -- and fully supported even by SAX 1.0 parsers.

The issue is what relative URIs denote in a context where there there's
unambiguous text in the XML 1.0 (2e++) spec.  That is, relative URIs
in system literals, before a catalog/resolver/... would see them.


> Moreover, I disagree with your position about SAX "permitting" something, as
> if it had a moral duty to withhold certain information.  SAX is an API and
> nothing more.  

It's an XML API, and I have a hard time seeing why it should be torqued
to address requirements that I read the XML spec as precluding.  There's a
cost to such changes (including XML spec revision), and in this case I've
seen no evidence of a real problem motivating any change whatever.

Let me turn it around:  If the XML spec says something works a particular
way, who wins by encouraging tools to work in some non-conformant way?
Surely not the XML community.


> Certainly SAX was not intended to report all the document properties that
> may be of interest to every application (hence the 'simple' in its title),
> it had to draw the line somewhere.  But the line was drawn to include entity
> resolution.  Now that we are seriously trying to use SAX to accomplish
> entity resolution a flaw has been found.

I've never once had a problem using the SAX EntityResolver in that role,
but then again I was working within the constraints of the XML 1.0 spec.

- Dave