Re: Public Identifiers, and CATALOGS

David Durand wrote:

> What we really want (if we are to use HTTP 1.1 effectively) is a way to
> fetch a "manifest" for the document, and then select and fetch the
> document, (one or more) stylesheets, and so forth, in whateever order makes
> most sense. In practice, probably style-sheet (if we don't already have
> it), DTD (if we need it, and don't already have it), document, then
> external entities. Now a CATALOG looks like a great nominee for the
> manifest. So much so, that I'm very tempted to say that we _should_ require
> catalogs, not for the PUBLIC->SYSTEM mapping, though that it a useful side
> effect, but so that we can require that the standard URL for a "document"
> may identifiy a CATALOG with a DOCUMENT entry, identifying where the XML
> parsing should begin.

This sounds very much like exchange from IETF Mime/SGML days. While a
proponent of exchange, I think this is too heavyweight for XML.

I've watched the debate and still don't understand the need to add PUBLIC
to the current draft. We have external entities whose declarations specify
URLs "which may be used to retrieve the content of the entity".

URL syntax is quite simple and goes something like:

  <scheme>:<scheme specific part>
  
To my knowledge, there is nothing preventing something like:

  fpi:<fpi specific part>
  
This is valid URL syntax and can be used by new applications as a means to
perfrom fpi resolution. Some applications (like today's browsers) will not
understand the fpi scheme and will fail. At some point in the future,
other applications will understand the fpi scheme and will perform resolution
based on some, as-yet-undefined mechanism. What's wrong with this picture?
It requires *no* modification to the current XML draft, is web-compliant, 
is easy to understand, does not require catalogs, and in short keeps XML
simple.

It is possible to make use of FPIs without the PUBLIC keyword. We do it
now at Sun by encoding the FPI in a URL of the form:

  http://host:port/<FPI stuff here>
  
While not ideal, we get all the benefit of FPIs on the publishing side, 
and *some* of the benefit on the browsing side. With XML browsers, we 
would use:

  fpi:<FPI stuff here>
  
and get *all* of the benefit on the browser side as well, unless of course
the keyword PUBLIC is the issue. If the keyword is the issue, could someone
please explain the importance of the characters "PUBLIC" as opposed to the
functionality they imply.

I believe that we already have a solution in the current draft that uses
existing (web) practice. I don't see why another mechanism is required. In
XML, one method is preferable to two or more. If two or more are required,
"full SGML" should be used.

(Apologies to anyone who proposed fpi:<fpi specific part> in the past. I'm
sure it has been mentioned as an obvious way to allow for fpi resolution.)

Received on Monday, 31 March 1997 22:22:56 UTC