Public Identifiers

G. Ken Holman gkholman at
Wed Sep 23 04:48:06 BST 1998

I've hesitated jumping in to the discussion since the SIG went through it
in detail so long ago, but something discussed back then has not been
raised in this forum where there are other participants who didn't see the
earlier discussions.

At 98/09/18 06:49 -0500, W. Eliot Kimber wrote:
>In hindsight, it's clear to me that we never should have allowed public IDs
>in XML.  

Two uses of Public Identifiers that have, I believe, been overlooked
throughout this discussion, and I feel I personally need, are (1)
receiver/user resolution when system id unavailable and (2) copy
identification (e.g. versioning).

(1) Consider I have an XML document on a CD-ROM (or password-protected for
write, or behind a firewall for write permissions, or some other condition
rendering it read-only).  It might be very large, so large I don't want to
copy it to a local environment where I can modifiy it.  I may not even have
permission to make a local copy in which I can modify it.

Now, some external resource refered to in the read-only file is identified
by both a SYSTEM identifier and a PUBLIC identifier:

 <!DOCTYPE pres
   PUBLIC "+//ISBN 1-894049::CSL::Presentations//DTD Presentation//EN"
   SYSTEM "">

The XML Processor discovers it cannot access the URL for whatever reason
(server down, firewall, whatever).

A Public Identifier Resolution Mechanism, if it were available in the XML
Processor, can obtain the necessary local copy if I give it information
about a copy I made some previous time when I did have access to the remote
resource.  And by changing the information to the resolution mechanism, I
can move it around freely without changing the read-only resource.

Without a public identifier, and without the ability to modify the
read-only resource, I would have to resort to some kind of System
Identifier remapping mechanism if it were available in the XML Processor.

I would think it "cleaner" to do public identifer mapping, rather than
system identifier remapping, though I will acknowledge both will end up
with the same results.

(2) In the life of a DTD, I may create a number of instances conforming to
different versions:

One day:

   PUBLIC "+//IDN RDF Version 1.0//EN"
   SYSTEM "file:///s|/rdf/rdf.dtd">

Three months later:

   PUBLIC "+//IDN RDF Version 1.1//EN"
   SYSTEM "file:///s|/rdf/rdf.dtd">

Three months after that:

   PUBLIC "+//IDN RDF Version 2.0//EN"
   SYSTEM "file:///s|/rdf/rdf.dtd">

Each one pointing to the same file that has been updated on the fly.

One feature of an XML Processor might be that if an error is detected
through the use of the resource found through the SYSTEM id, offer to the
user to begin processing again through the resource found through the
PUBLIC id without obliging the user to change the source file.

I'm emphasizing the temporary nature of this feature, perhaps because this
is a one-off run for the user.  For conformance reasons the governing DTD
is the one found through the SYSTEM identifier, so it shouldn't be default
behaviour of a processor to categorically "try again" with the PUBLIC
identifier when there is a fault using the SYSTEM identifier ... but a
courtesy "restart with override" feature might be offered once the
conformance requirement to stop has been met.  

This second issue is fuzzy, but I hope I've conveyed how the following
resolution of the public identifiers would help:

   PUBLIC "+//IDN RDF Version 1.0//EN"
   PUBLIC "+//IDN RDF Version 1.1//EN"

I'm more interested in the utility of the first issue.

To me it makes more sense to map public identifiers than remap system

............. Ken

G. Ken Holman               mailto:gkholman at
Crane Softwrights Ltd.
Box 266,                                V: +1(613)489-0999
Kars, Ontario CANADA K0A-2E0            F: +1(613)489-0995

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list