Re: XML catalog draft
email@example.com (Paul Grosso) writes:
>> From: firstname.lastname@example.org (Murray Altheim)
>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"
>> This announces to the world that the document conforms to HTML 2.0, but
>> tells the processor that a local copy of 'html.dtd' will provide the
>> resource without resorting to a PUBLIC catalog lookup. IOW, why bother
>> resolving the reference if the document seems to know where to look. Then,
>> if the SYSTEM fails, resort to the more generalized process of a catalog
>> lookup using PUBLIC.
>But suppose I have a local copy of the HTML 2.0 DTD (and who wouldn't),
>so my local system default catalog has:
> PUBLIC "-//IETF//DTD HTML 2.0//EN" "/home/dtds/html.dtd"
>If you prefer SYSTEM, then there is no way to find the local copy in
>favor of the spyglass one (unless the latter fails).
I didn't mean to imply a behavior at all. What that DOCTYPE says is that
there are both SYSTEM and PUBLIC available, not which one is given
preference. I'm not advocating constraining UA behaviour. Your converse
>In other words, in answer to "why bother resolving the reference if the
>document seems to know where to look" I'd answer "why bother to have a
>public id that allows the all-important indirection if you going to
>ignore it in most cases."
is true iff the UA is set to prioritize SYSTEM over PUBLIC. Please note
that I was not stating that converse, I was replying to David's statement:
email@example.com (David Durand) Tue, 11 Feb 1997 13:57:52 -0500 writes:
>Since PUBLIC is likely to be a point of user-tailorability, it should be
>looked at first -- implementations that don't implement PUBLIC resolution
>will simply ignore the PUBLIC, thus causing it to "fail". I can't think of
>a case where someone who _has_ working public resolution, would prefer to
>use the system ID -- andif they did, it seems they could always ensure that
>any given public ID (or all) would fail to resolve.
by trying to state that a general, simplistic rule is not possible.
>Public ids aren't just a fallback for broken URLs, they are a very
>important way to manage indirection of resource name resolution.
Agreed. I'm in agreement with David's last summary on the subject:
>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.
Murray Altheim, Program Manager
Spyglass, Inc., Cambridge, Massachusetts
"Give a monkey the tools and he'll eventually build a typewriter."