Re: SAX 2.0 enhancement proposal

[Norman Walsh <ndw@nwalsh.com>]

/ David Brownell <david-b@pacbell.net> was heard to say:
[...]
| 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).

I don't believe that assertion is in question, however, Section
4.2.2. says:

  [Definition: The SystemLiteral is called the entity's system
  identifier. It is a URI reference (as defined in [IETF RFC 2396],
  updated by [IETF RFC 2732]), meant to be dereferenced to obtain
  input for the XML processor to construct the entity's replacement
  text.]

Note that it says "meant to be dereferenced". It does not say "must"
be dereferenced.

  It is an error for a fragment identifier (beginning with a #
  character) to be part of a system identifier. Unless otherwise
  provided by information outside the scope of this specification

I believe it is entirely consistent for the entity resolution
mechanism to be considered information outside the scope of this
specification.

  (e.g. a special XML element type defined by a particular DTD, or a
  processing instruction defined by a particular application
  specification), relative URIs are relative to the location of the
  resource within which the entity declaration occurs. A URI might
  thus be relative to the document entity, to the entity containing
  the external DTD subset, or to some other external parameter entity.

In addition, it says:

  [Definition: In addition to a system identifier, an external
  identifier may include a public identifier.] An XML processor
  attempting to retrieve the entity's content may use the public
  identifier to try to generate an alternative URI reference.

Clearly then, the system identifier does not have to be dereferenced
since an alternate URI may be constructed by the parser if it chooses.

Note also that the XML2e Rec also does not say that an entity resolver
is forbidden from considering the existing system identifier in
addition to the public identifier in attempting to generate an
alternate URI reference.

  If the processor is unable to do so, it must use the URI reference
  specified in the system literal. Before a match is attempted, all

Clearly the fallback is that the system literal must be used if no
other alternate URI can be found.

| 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 don't understand your conclusion at all. Why is it the case that
this doctype declaration:

  <!DOCTYPE foo PUBLIC "-//Example//DTD foo" SYSTEM "../foo.dtd">

must be presented to the resolver as

  public="-//Example//DTD foo"
  system="file://path/to/absolute/foo.dtd"

Why is it not equally reasonable for the resolver to be presented with

  public="-//Example//DTD foo"
  system="../foo.dtd"

since that's actually what the document *says*.

If the system identifier that the parser finally winds up using is a
relative URI reference, it's clear that it's relative to the base URI
of the containing entity. As I said before, I don't think that's in
dispute.

What I have never understood is why the SAX API feels that "early
absolutization" is preferable to "late absolutization".

| >     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.  They're very easily
| mis-understood, since implicit context is easy to get wrong.  Why is
| this catalog draft trying to encourage/facilitate error-prone and
| complex idioms?  Which, moreover, are intended to violate the XML
| specification?

I assert that they do not voilate the XML spec. As to why, because it
is both more flexible and more consistent with TR9401.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM   | 'I have done that,' says my memory. 'I cannot
XML Standards Engineer | have done that'--says my pride, and remains
Technology Dev. Group  | adamant. At last--memory yields.--Nietzsche
Sun Microsystems, Inc. |