OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SAX 2.0 enhancement proposal



This bounced. Forwarded for reference.



At 12:10 2001 06 13 -0700, David Brownell wrote:
>> 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 ...

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

>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:
ftp://ftp.ietf.org/rfc/rfc2396.txt
http://www.w3.org/TR/xmlbase/
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:
http://www.oasis-open.org/committees/entity/

paul