[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SAX 2.0 enhancement proposal
- From: Norman Walsh <email@example.com>
- To: firstname.lastname@example.org
- Date: Wed, 13 Jun 2001 15:59:04 -0400
This bounced. Forwarded for reference.
- From: Paul Grosso <email@example.com>
- To: David Brownell <firstname.lastname@example.org>, Rob Lugt <email@example.com>,firstname.lastname@example.org
- Date: Wed, 13 Jun 2001 14:44:55 -0500
At 12:10 2001 06 13 -0700, David Brownell wrote:
>> The XML Catalog draft specification  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 ...
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
>> 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. Most people, including
the authors of RFC 2396 (with includes Tim Berners-Lee) feel they are
>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.
If you read RFC 2396 and/or the XML Base spec:
you'll find the explanation of how to absolutize relative URIs very explicit.
Relative URIs are something that is used every day by many people.
> 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.)
The SGML Open/OASIS catalog was very useful to many people, and there
are a fair number of experts who feel it was a mistake not to include
something like that in XML. The OASIS Entity Resolution Technical
Committee has a number of non-Web-naive XML experts on it working to
create an XML version of such a catalog that we think will be very
useful to many people. You can find out more about the work at: