Re: XML catalog draft

dgd@cs.bu.edu (David Durand) writes:
>This is correct for a local file system, but incorrect, I think, when
>SYSTEM IDs are URLs. A URL in general requires the invocation of a network
>query, whereas a catalog may be resolvable with purely local (and hence
>cheap) operations. In your example, I can, without a cache, determine from
>the PUBLIC ID that I have a local file containing the correct DTD. The
>SYSTEM ID just tells me that your HTTP server also has a copy in that
>place. Of course a local URL cache could invert this preference...

Well, I inadvertently made the point that resolution is more complex than
PUBLIC vs. SYSTEM. "www.cm.spyglass.com" is a local server *for me*, but
not for you.

>Perhaps we should leave the resolution strategy to the client, as I can
>imagine rather complex, but very sensible strategies. For instance:
>  Prefer local SYSTEM IDs to any CATALOG method
>  Otherwise, use the local CATALOG to resolve by PUBLIC ID
>  Otherwise try any (non-local) SYSTEM ID
>  Finally, try non-local CATALOG resolution (perhaps extended SOCAT).
>The above strategy may actually be quite good for a typical browser
>application that. In fact each of the SYSTEM resolutions could be further
>modified by a SYSTEM ID cache check, which should precede any
>network-invoking operations...
>Depending on how  the software caches data, the optimal strategy may be
>very complex. I'm now thinking we should not get in the way of processing
>agents defining their own strategies _however_ they want to.

Agreed. It seems out of place for an XML specification to specify this type
of behaviour.


    Murray Altheim, Program Manager
    Spyglass, Inc., Cambridge, Massachusetts
    email: <mailto:murray@spyglass.com>
    http:  <http://www.cm.spyglass.com/murray/murray.html>
           "Give a monkey the tools and he'll eventually build a typewriter."