Re: SAX 2.0 enhancement proposal

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

My response to Rob's proposal started:

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


Paul Grosso responded:

> I disagree as does most of the XML Core WG.  Clearly, some catalog
> resolution is necessary for public ids, so the XML spec does not
> prohibit that.  The fact that a catalog aka entity resolver might
> be used to remap system ids is make clear by the E3 erratum that
> you can find at http://www.w3.org/XML/xml-V10-2e-errata#E3

Please don't confuse the issue by implying I was talking about remapping;
I clearly wasn't.  I responded specifically to the issue affecting interpreting
of relative URIs.  That erratum relates ONLY to remapping.

I don't have a problem with remapping.  It's logically the same thing as
choosing a cached copy, and it's already facilitated by SAX.  Relative
URI resolution is a substantially different function ... preceding remapping.

Curiously erratum E18 modifies the exact text I referenced, but only
by clarifying what was meant by the "resource within which the declaration
occurs" (internal PEs aren't eligible).

Given that, I can't see _any_ evidence that "most of the XML core WG"
believes that the clear text of the XML 1.0 spec is wrong.


> >>     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.  
> 
> That is an arguable statement with no backing.

Experience doesn't count as backing, in your world?  :)

Saying something is arguable is easy -- just argue, point proven.
I've used that trick too, but it doesn't usually get anywhere.


>      Most people, including
> the authors of RFC 2396 (with includes Tim Berners-Lee) feel they are 
> very useful.

Yes, well I seem to recall a rather extensive debate about what relative
URIs mean in a few contexts.  Like namespace URIs. I think that the
months of flamage on that were a reasonable example of "trouble".  I've
seen similar examples inside many systems that overuse relative URIs.

The XML spec defined relative URIs in a clear and useful way -- which this
proposal wants to ignore/abolish.  It's not that all relative URIs are trouble; but
when you've seen the number of security holes coming from flakey schemes
to remap them, you might start pulling out the garlic when another one comes
up, too.  (Ever been in symlink hell? :)

Simple rules are useful; complex ones are generally trouble.


> >They're very easily mis-understood,
> >since implicit context is easy to get wrong. 
> 
> I'll grant you that some things about URIs can be easily misunderstood,
> but being easily misunderstood is not a good argument against something.

That's a philosophy it's worth rethinking a few times!  There are costs to
complexity.  The original "Big Win" of XML was simplicity.  Complexity
isn't always bad ... but neither is it a good thing which should be accepted
without questioning.  In this case, there doesn't even seem to be a real
problem that needs addressing, it's complexity-for-complexity's sake.

- Dave