Re: SAX 2.0 enhancement proposal

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

> David Brownel wrote:

(surely you can spell my name right, Rbo :)

> > 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.
> 
> The [draft] specification refers to system identifiers from the xml
> document.  SAX 2.0 is manipulating these sytem identifiers before passing
> them to the Entity Resolver.  This is the problem.

I still feel like you're ignoring my basic point:  if that draft expects to interpret
those identifiers in conflict with clear language in the XML specification, the
bug is in that draft, not SAX.  From false assumptions, anything can follow.


> > 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.
> 
> I absolutely agree with this statement, but from where I'm standing it is
> the current version of SAX that is acting in a non-conformant way.  James
> Clark pointed out [1] that the proposal (with his modifications) moves SAX
> more into line with the XML Infoset specification [2]. 

But that would apply only to UNPARSED entities (or presumably notations).
See my separate followup -- handling of entities that are PARSED by an
XML parser is subject to different treatment, even in the infoset.


> > 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.
> >
> 
> Well, you must have been working to a narrower set of requirements.  The
> OASIS entity resolution TC are creating a specification that will satisfy a
> diverse group of users.

I don't think it's a good thing for an XML API to address users who want
nonconformance with the XML specification.  That's the sort of process
which undermines standards.  If a feature is that all-fired important, then
it's worth formally revising the XML specification (and infoset).

- Dave