Re: What to do given both SYSTEM and PUBLIC?

> There is no consensus on how PUBLIC should be interpreted.
> Different peole want it as a hook for different things.
> 
> It's a recipe for disaster.

No it's not, it's quite clear-cut:

> If we open the can of PUBLIC worms, we have to say:
> * what to do if you are given a PUBLIC Id and no SYSTEM Id

1. Resolve it, either algorithmically or using a catalog.
   If that doesn't work then you do indeed have a problem,
   and the browser can't be blamed for the deficiencies of
   the author in failing to provide the right info.

> * what to do if you are given both

2. Browser-configurable preference.

> * what to do if you are given both and the resulting files are different

3. Never occurs: you use the one you get first from (2) above. If you've
   resolved one successfully, why on earth would you want to fetch the
   other one?

> * give at least one way in which I can put an XML file on the web and
>   someone else 6 months in the future with some new application can
>   use that file, whether or not it has a PUBLIC Identifier.

That doesn't make sense: the question is surely, how can someone use
that file whether or not it has _some kind of identifier_, sys or pub?
If you provide no identifier, then the instance has to be well-formed
only, and the question falls.

> Otherwise...
> 
> Some people will implement systms that ignore the PUBLIC ID, as
> David Durand and Paul Prescod suggest, and always require a SYSTEM Id.
> 
> Some people will implement systems in which the SYSTEM Id is ignored,
> as Paul Grosso suggests, when both are given.
> 
> Some people will implement systems in which the SYSTEM ID is used for
> some things and the PUBLIC for others, as per Panorama today.
> 
> Some people will implement systems that require end users to edit local
> configuration files before they can use documents containing PUBLIC Ids,
> as per Author/Editor today.
> 
> No document will work on all systems.

It strikes me that the authors of such systems need some serious help.
Perhaps (as often looks all too frighteningly obvious) they've never
actually had to _use_ their software to do a job of work.

I'm delighted to see that at long last this problem is being taken
seriously. 

> If we give a set of rules for which to prefer, as I have several times
> said, we will end up with interoperability, and you will then be safe
> to use XML in systems where you have no control over the recipient,
> rather like HTML today.
> 
> If we don't have PUBLIC at all, this problem goes away.
> I would rather wait six to twelve months before adding PUBLIC.

We may have to agree to disagree on this, but I'm willing to be
persuaded. The problem is that the PUBLIC identifier is the "real" (ie
formal) name of my DTD. I don't care what filename you give your
locally-cached copy, or what filename someone calls their version
available via a URL. What is crucial is that if I identify my document
as being "-//Davenport//DTD DocBook V3.0//EN" then that is what it is,
nothing more and nothing less. Trying to fudge the issue of public DTDs
without PUBLIC identifiers, trying to rely on someone's localised
concept of what they might want to call the DTD file on the third
Tuesday after the full moon, is a guaranteed recipe for disaster. Where
private DTDs are concerned, by all means stick with SYSTEM ids. I just
cannot believe that people seriously mean that a browser is capable of
doing the right thing when given <!doctype html system "html.dtd"> when
there must be 100 or more DTDs all claiming to be that.


Where we agree 100% is that we need a set of rules, and they're nearly
all binary choices, so it's just a large nest if if-then-elses.

///Peter

Received on Monday, 17 February 1997 12:36:58 UTC