[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SAX 2.0 enhancement proposal
- From: David Brownell <firstname.lastname@example.org>
- To: Rob Lugt <email@example.com>, firstname.lastname@example.org
- Date: Fri, 15 Jun 2001 07:37:46 -0700
> 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  that the proposal (with his modifications) moves SAX
> more into line with the XML Infoset specification .
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).